If Deno has no Node compatibility then you know that no Deno library pulls Node modules in with it, because it's impossible. The more seamless node interop becomes, the harder it will be to sift the Pure Organic Deno libraries from the NPM-infused Deno libraries.

So, on the contrary: Node becoming embraced by the wider ecosystem absolutely hurts pure Deno projects because they'll rapidly become perceived as a fundamentalist minority that doesn't need to be catered to, where the original idea was that all projects would be pure.

Seems like it could easily just be a compiler flag to 'only allow pure deno' and then fail/warn if a dependency pulls in npm stuff.

I think a flag like that shouldn't have to exist. It's complicating and bloating the runtime more just to gain more adoption, not to make Deno actually better.

I think not wanting to pull packages in from the largest package ecosystem in JS land is a fairly marginal need which should only be catered to through a setting, if at all.

You can always not add NPM packages if that’s something that bothers you, and there are probably fairly simple ways to add a lint step that ensures you’re doing that by simply scanning your package.json (which makes me think…can’t you simply not add a package.json? The original direct URL library references will be around anyways).

You just have to also lint your URL imports for "npm:" URLs. That's an easy enough lint. (Though slightly more complicated if you also decide to block in your lint rule other common npm-based CDNs like unpkg/esm.sh/others.)

I don't buy it, you can already use stuff like skypack or other bundling CDNs to import npm modules in deno just by their URL.

You have a very bizarre argument that I don't follow. I don't care about the "purity" of the project, I care about getting shit done and deno is helping greatly there.

> I don't buy it, you can already use stuff like skypack or other bundling CDNs to import npm modules in deno just by their URL.

It's not that simple if the project you are importing uses Node-specific APIs. By the way, this is an area that can really confuse newbies.

then you're stuck with a CDN you don't control. The runtime (Deno) being able to work directly with most packages on npm is a huge win because I don't have to trust a 3rd party for this anymore, and that to me is a big win.

Agreed, I'm just refuting the reply above that deno just recently besmirched some bizarre purity by adding friendly node NPM support. From the very beginning of deno you could import any JS code, including simple stuff from npm that didn't rely on them unsupported node APIs.