Should node.js distributions bundle eslint?

[jasnell]

eslint has become the defacto standard lint tool for Node.js applications and it's a project under the OpenJS Foundation. Feedback from the community suggests that there would be value in bundling a linter with the Node.js binary. Experience with bundling npm shows that this can be a mixed blessing, particularly if an alternative competitive linter implementation comes along in the future. That said, I think the benefits outweigh the potential costs here, and we already include eslint in our source tree.

Thoughts?

btw: this is coming up due to feedback from parts of the ecosystem that deno's bundling of certain tools (like a linter, formatter, etc) improve the developer experience and make it a more attractive target.

/cc @nodejs/tsc @nodejs/releasers

[bnb]

Would this include shipping a rule set, or just shipping the linter module?

[jasnell]

A default minimal rule set.

[wesleytodd]

At the risk of making many folks mad, I think an opinionated and robust rule set would be better for the entire user base than a minimal set. The formatting rules (similar js linting in theory) which the go ecosystem ships is, IMO, a great decision. This would be much harder to do in such a diverse and large ecosystem, but that only increases the value of such a decision being made.

EDIT: I hate some of the rule decisions in standard, yet I use it and love the productivity I have gained since I stopped maintaining individual eslint configs across many projects and would love to see the same out of the ecosystem at large.

[nzakas]

I’m not sure that this is a good idea. The usage patterns for ESLint and npm are quite different, and I’m not sure a dev tool like ESLint could be effectively used as a bundled tool.

To start, we do releases every two weeks. That poorly aligns with the Node.JS release cycle, and needing to schedule our major releases to coincide with a Node.JS release for best compatibility would be a big headache for us.

I’m happy to discuss more details either here or on the phone, but please don’t bundle without talking with us (the ESLint team) first.

[l-mbert]

I personally like to manage things like ESLint for myself, but would certainly like the simplicity having the linter integrated. At work I often switch between Node versions due to legacy codebases and switching between different Linter versions would be kind of a headache in the long run.

Would it be optional to the point that we could disabled it without any Environment variables or something set and we could use our installed ESLint or would a default minimal rule set always be in place? (If this is without a question then sorry for the unnecessary reply.)

[vdeturckheim]

An alternative solution would be to bundle an unspecified linter (eslint at first) with a configuration (the one used by the Node.js project) behind an alias command (js-lint, nodelint, you name it). In that case, the implementation details do not really matter and we can switch the base tool later as long as the changes in the configuration are managed as release updates/breaking changes.

[pipobscure]

NodeJS is a runtime environment. Even npm should not be bundled with it. It’s also one of the main reasons I personally dislike deno so much, since it includes random stuff like TypeScript etc. If node starts bundling more arbitrary junk, it’ll in the end become less useful to many including me.

If I had my druthers (and I realise that ship has sailed) NodeJS wouldn’t even include the built-in modules (fs, net, http, ...) but rather keep them as external native modules.

So here is me begging you not to go down this road.

[cjihrig]

A few thoughts if Node were to go this route:

• I have shipped my own pre-configured linter built on top of ESLint for over five years. The maintenance overhead has been extremely minimal. I usually just release a new major when ESLint does. However, that might not work for Node's LTS releases.
• Shipping the ESLint configuration used by Node as-is (as suggested by @vdeturckheim) is not an option due to some quirky custom rules that are only useful in core.
• Node might want to ensure that nothing about the underlying implementation is visible to end users. If we don't expose ESLint directly, then we need maintainers for the Node linter, potentially with knowledge of ESLint internals as well.
• If ESLint were exposed directly, what is the plan to prevent needing a linter manager, similar to the current package manager manager discussion?
• How are the default rules/configuration going to be selected? For example, are semicolons enforced?

[patoi]

Shipping Node.js with configurable, optional "node project initialization" code: init linting, formatting, testing, etc, etc. This is just an idea. It helps beginners. For example: https://start.spring.io/

[wesleytodd]

Shipping Node.js with configurable, optional "node project initialization" code

The @nodejs/package-maintenance team has started work on a community managed replacement for npm init. There are many things which make that conversation difficult and I would recommend this conversation focus on just the OP question of shipping ESLint and the pros/cons of that decision.

[ljharb]

eslint has updates every 2 weeks (oops, posted this before seeing eslint's creator having already said the same thing). shipping it with node almost guarantees that folks will be stuck on old versions of eslint for a long time.

The more things are bundled into a platform, the more ways the platform can break. I think if node bundled more of these sorts of things, it would be significantly worse than the status quo.

As for a recommended config, certainly not node's own wildly unidiomatic config - but as I've learned from maintaining a very popular styleguide, node in no way wants to invite the bikeshedding and debate that providing defaults would inevitably do.

[tmkn]

This sounds like a solution looking for a problem.

Not everyone who installs nodejs wants to also develop with it, as such if all you want to do is setup the runtime, bundling eslint becomes useless.

[jasnell]

The twitter poll blew up but has maintained a consistent ratio from the beginning

The opinions on this idea range from "Do Nothing" to "Heck Yeah! Bundle all the things!", which is unsurprising.

There seems to be consensus that bundling a linter outright would not be a good thing but there does seem to be at least some appetite for a simple, highly opinionated but limited tool for checking for "obvious errors". It's difficult to define exactly what scope that would be. It would also be difficult to limit the scope on (once these tools get added, "feature requests" become A Whole Thing(tm).)

We do already have the -c/--check command line flag that parses and reports syntax errors. It's conceivable that could be expanded to perform additional limited checks, taking advantage of the already bundled in acorn dependency. We'd have to define the scope of such checks tightly and clearly. (For example, the tool could check for uses of deprecated APIs, known problematic anti-patterns, incorrect calls to core APIs, etc)

[benjamingr]

I do think the tools for setting up/running the project should be easier and there are too many tools to set up - but bundling eslint seems a bit much.

What about a node init command that initialises an empty project with good defaults (like type:package) and installs reasonable development time dependencies (like eslint) - it'd be like a non-empty npm init kind of like cra the ng cli or the vue cli.

I think a foundation poll to understand how people are initialising projects would be very interesting (though since those are much work I don't think we should necessarily wait for one before experimenting)

[ljharb]

@benjamingr what is "type:package"?

I think that an opinionated command like that doesn't belong in node at all, but certainly not without extensive adoption in userland first.

[benjamingr]

@ljharb sorry - I meant "type": "module" I'll type less on my phone 😅

[ljharb]

@benjamingr in no way is there consensus that type module is a good default; having the "type" field certainly can be a good default. All it does is change the parse goal of .js files; there's nothing objectively better about this.

[benjamingr]

@ljharb the compelling reason I see for something like bundling eslint in Node core is to reduce the mental overhead for developing Node projects.

Currently, developers have a quite high barrier:

• There are two module systems - which do I use? Do I need to learn both?
• There are two APIs for everything (callbacks and promises) - which do I use? Do I need to learn both?
• What do I do about code style and static errors? What package do I use for it?
• What do I use for code-formatting?
• How do I run my code in production? What steps do I take?

Deno answers these with:

• Only ESM.
• Only Promises.
• Run deno lint.
• Run deno format
• Run deno compile and execute it as a single program or run deno install.

I think we need to strive to a lower mental overhead. I believe it is currently quite confusing for developers to get started with Node.js

[jasnell]

lowering the cognitive overhead is a key motivator here. We are consistently hearing from a non-trivial subset of the Node.js community that making tooling selection for Node.js if difficult and there are way too many inconsistencies. The prevalence of so many different bootstrapping tools (npm init, create-react-app, etc) would seem to illustrate the point as the whole point of these is to reduce the burden of making the same decisions over and over.

Perhaps what would be most helpful, rather than talking about individual tools, would be talking about how we can make bootstrapping easier... with a built-in facility for node -init {whatever} where the {whatever} is filled in by the ecosystem rather than Node.js. It could work, for instance, in pretty much the same way as npm init {whatever} (e.g. try npm init fastify) which is already a paved cowpath.

$ node --init getting-started

[styfle]

@jasnell In that case, it seems like you wouldn't need any changes to Node.js at all.

Just publish a new package create-getting-started to npm and it will work with existing npm init getting-started.

Is there something that node -init would do differently than npm init?

[jasnell]

@styfle ... the idea would be to have something that works independent of which package manager you're using. So, for instance, if you were using yarn... node --init would still do the right thing.

[styfle]

@jasnell Are you aware that yarn has the analogous command: yarn create getting-started?

You could also do npx create-getting-started.

I'm still not sure this would add any value unless Node.js plans to stop shipping npm.

[benjamingr]

@styfle basically having a blessed create-getting-started package in NPM and having "blessed" instructions in our docs explaining how to get started with a pre-configured set up with scripts for lint/build/format would address the problem (in my opinion) as well *.

The important bit is for users to have to make less choices (while being able to make choices if they want to).

(*) assuming we make sure the tools included only update after audit from a collaborator.

[ljharb]

The blessing is the controversial part.

I don’t think there’s an obvious answer as to whether “opinionated decisions so you don’t have to choose” or “you choose your setup but maybe it’s hard to know what’s good” is a better option.

[benjamingr]

I don’t think there’s an obvious answer as to whether “opinionated decisions so you don’t have to choose” or “you choose your setup but maybe it’s hard to know what’s good” is a better option.

I agree - I think there is no objective truth here and I think it is hard to know what's good (especially since what's good is changing and usually hard to establish consensus around).

That said tools like create-react-app have been very successful in reducing mental overhead from what I understand, especially how hard getting started is becoming.

So I guess what I'm saying is "I believe this is a common complaint and a big problem" and "It's important that we solve it and I'm happy the conversation has started".

(Also, I believe most people are aligned around ESM and promise APIs are the future and CommonJS and callbacks eventually taking a back-burner while being supported forever - although that would definitely have to be established before we take any action based on that assumption)

[jasnell]

The blessing is the controversial part.

And this is the actual problem. What this subset of users is telling us is "Please! Node.js be opinionated and make some decisions for us!"

If the answer is, "Ok, you can use npm, npx, yarn, or any of these other tools to do that".... then we're not actually answering that feedback. That's exactly opposite of being opinionated. I don't think the answer to this subset of users is #wontfix.

Yes, I would like to imagine a future where we actually don't ship npm by default but where node --init getting-started pulls it down as part of the standard opinionated toolchain. That would open the door to other variants, like node --init getting-started-yarn where what you get is yarn instead.

[pipobscure]

I don’t like the assumption that Node is only used for development. If I install it on my server, I most certainly do not want eslint or other junk on there ever. Including it in Node would be a reason to explore alternatives.

Beyond that, if the mental overhead to choose and install your tools is too much for you, then development is too much mental overhead for you as well.

Node has proven that this mental overhead is not too much, even for inexperienced developers. Node has on boarded countless developers of every level.

So my take-away is that: The benefit is marginal at best, and nothing that can’t be easily done with npx; while the detriment is substantial and the opinionated decisions required would be divisive at best and likely even destructive.

[jasnell]

@pipobscure ... I'm actually arguing in the same direction as you are here. Let's actually remove the tooling that ships with node.js by default (npx and npm included) and provide node --init as a way of bootstrapping that tooling as needed for anyone who does want a developer toolchain.

[benjamingr]

Beyond that, if the mental overhead to choose and install your tools is too much for you, then development is too much mental overhead for you as well.

I would really prefer it if we avoided gatekeeping here 🙏

Node has proven that this mental overhead is not too much, even for inexperienced developers.

Though people have been complaining to devs about this problem - and in fact it looks like a bunch of people here do think it's an issue worth discussing.

[ljharb]

It's important to realize, though, that the existence of people unhappy with the status quo does not preclude (nor ensure) the possibility that a much larger group of people would be unhappy with changing it.

[jasnell]

The line of discussion here has become unproductive. Yes, we're talking about opinions and about being opinionated, and by the very definition of the term there will be folks who disagree. So let's short circuit the unproductive hand waving about that and stipulate, yes, there may be some people unhappy with literally anything we decide to do.

Now, let's get back to the more productive thread... here's how the twitter poll I ran landed:

While it is far from scientific, this would suggest that there is certainly a non-trivial portion of the ecosystem that would like us to consider doing something other than the status quo here and what I'm doing here is trying to figure out that could be. We already know that "do nothing, keep it the way it is" is a reasonable option in the list of things to do. We also have on the table "just remove all the tools, including npm".

What I'm most interested in discussing here is this: Given that a non-trivial portion of our ecosystem has told us that they are unhappy with the current developer experience, what, if anything, are our options for improving it?

[benjamingr]

While it is far from scientific, this would suggest that there is certainly a non-trivial portion of the ecosystem that would like us to consider doing something other than the status quo here and what I'm doing here is trying to figure out that could be.

I think this data also suggests that this is not clear-cut as it may appear and a pretty significant portion of users object to including eslint.

To me this suggests that a solution like node --init is more viable than packing a global eslint binary.

[bnb]

While it is far from scientific, this would suggest that there is certainly a non-trivial portion of the ecosystem that would like us to consider doing something other than the status quo here and what I'm doing here is trying to figure out that could be.

I've worked at two companies now that have done a lot of work to understand how many people are in the JavaScript ecosystem, and I'd really like to ensure that we're not classifying 2000 people as a statistically significant set of input. Saying that it's a non-trivial portion does that, effectively, especially given that it's on Twitter which has a limited subset of the ecosystem, doesn't reliably show it to people naturally and without bias (timeline algo) and relies on amplification which then introduces community biases.

[jasnell]

#bnb :

I'd really like to ensure that we're not classifying 2000 people as a statistically significant set of input

Thus the words "far from scientific" and "suggest" ;-). I'm saying there is a demand without trying to quantify what that is. We don't have to rely solely on this unscientific poll. We can look at the recent discussions around yarn and pnpm, we can look at the motivations behind what makes npx an attractive tool, we can look at the popularity of scaffolding tools like npm init, create-react-app, and so many others, we can look at trends in other tools (like deno), we can look at the direct critical feedback that Node.js has received from users and former users, we can look at the myriad of common repeatable steps necessary to bootstrap new projects (install a linter, install a test runner, install a formatter, install a bundler, ...)... there's so much we can look at to give us enough justification to take a step back and have a conversation about whether there's something we can do here to improve developer experience.

[marsonya]

A default minimal rule set.

A kind of recommended set of rules for Node right?

[marsonya]

node --init sounds really interesting to me.
npm, yarn or none
eslint, jslint, standard or none
google style guide, airbnb style guide or none (if linter is selected)
axios or none
and a few more...
maybe something related to typescript too?

this could help node provide users with a wide range of tooling options
and help developers avoid tooling they don't need.

in a way, scaffolding is wildly popular now a days.

[urugator]

I don't believe one can reduce cognitive overhead by adding things and if I follow correctly the only thing that is being removed here is a single command npm i -g eslint. All other complexity related to eslint, it's usage, configuration etc is still present.

Some interactive opinionated npm init like command that would hint what's in the store and help creating a project of certain type (library/server/browser/etc) ... would be cool I think. Still not sure if it needs to be part of node though.

[mhdawson]

I think @wesleytodd already mentioned https://github.com/pkgjs/create in which there is already work/discussion around helping to scaffold a package but I'll potentially repeat as it might be a good avenue for some of what is being discussed.

[pcjmfranken]

The only problem that I can see bundling these "editor's favourites" packages would really solve, is to save people from having to run some installation commands and save them from having to go to these respective tools' docs and actually read up on that piece of software they will be using.

On the other hand:

• You'd be saddling yourself up with more maintenance and support overhead
• What gets added and what not, where does it end? Who will decide? What would it cost - either openly or under the table -to have my (hypothetical) library bundled and will you accept dogecoin?
• Many workflows would be disrupted, many projects will never move past the last pre-bloat Node version
• Even more security liabilities and vulnerabilities (the elephant in the room already, this topic seems to be :) )
• You would pull the rug from under any competing projects and even remove any incentive for anyone to ever start one, thereby stifling innovation
• The current trend of expecting things to just work™️ and the results of when it doesn't is unhealthy and, to me personally, even concerning

Stick to being that quiet but reliable and predictable foundational layer. Support ecosystem developments in a guiding and mostly unopinionated manner. One that doesn't do Twitter polls.

Third party peripherals such as ESLint really don't belong in a core runtime package. If is really that important it should be a proper core module.

[melroy89]

No.. NodeJS is actually considering to split the package manager (npm) from NodeJS.

Now you even want to add more programs to the same NodeJS package? Making it even worse. When there is a bug in Eslint a new NodeJS package needs to be released, because you bundled it all together. This is insane if you think about it.

[Trott]

Oh, wow, this issue is still open? Closing. Re-open if someone wants to make the case for this, but it's been dormant (until an hour ago) for almost 3 years.