Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
I really liked that you stand up to the TC "decision" (hopefully) since I am also not quite happy with the current state.
That being said given that I call the current proposal
You may not want to mock us if you actually want buy in from the CTC. (Which whatever is accepted in the end will require, obviously.)
I should probably make it clear that the CTC doesn't really like any of the solutions but that the extension is the most favorable of the bunch. Ideally we wouldn't need anything special but that isn't possible when you have two possible filemodes for a file and need to avoid double-parsing.
It is probably favorable if npm does not need to do anything. I think we've probably caused even more of a mess if that is necessary?
Not exactly positive imo
It's pretty important that
Updating the cli to support new registry semantics and updating the npm registry to support them is, relatively, "easy". (I say as the person who only has to be concerned with the former. =p)
But how do you select variants for git dependencies? What about tarball dependencies? What do you do when talking to a third party registry that hasn't implemented this yet?
You might say "well, don't publish things to the third party registry using this feature" except that many of them act as transparent caches for the npm registry.
Making changes to package selection semantics is, I think, best kept outside the scope of any es6 module proposal.
@Fishrock123 I did not mean to mock you in any way. I just hoped it is not a final decision - it can be changed. That is why I posted it as comment here, in this repo, that seems to be of same sentiment.
I would be curious about why not?
Thank you for the insight @iarna . I think though this also could be easily taken care of. Let me extend the the Proposal a bit:
Support for old registries/proxies
The current registry and proxies should have no problem to support the "syntax" property do not support package variants. When npm@4 tries to publish a package with multiple variants to a server that doesn't support (different endpoint) multiple variants the package owner will be informed of this and he needs to specify
If the proxies or registries don't upgrade they will by-default get the
npm could help make this situation better. I think it is worth to explore this path. After all this decision will affect pretty much everyone.
Ah, alright. Apology accepted.
Generally we don't do specs and so anything that isn't existing functionality is up for change, to a degree of course.
This is a very, very big misinterpretation of the size of the ecosystem and how much time people have to transition, and generally the availability of downstream users to adapt on a dime. We'd rather be a bit "wrong" than hurt everyone hugely.
Perhaps, but why should they have to? If they must, node core has failed in a sense. Plus npm is already super busy so I'd rather we don't hold them up on this too.
Transitionary packages are packages that contain both es6 and commonjs modules. there is no penalty for commonjs only packages. Also it needs to be clear that this "penalty" consists of a compile script that compiles mixed sources to commonjs. (not at all a huge penalty imho)
This could also make way for implementing frontend packages which is on the agenda of npm. Also I think that implementing es6 modules will affect them quite a bit (i guess) in their work. So: @iarna 's opinion surely matters a lot.
Any time I think about es6 modules I get uncomfortable feelings around forward compatibility for published modules. The current status quo, which is that you write your modules in whatever and compile to es5 at publish time, pretty much guarantees forward compatibility.
That is, not only do newer versions of node & npm continue to work with older modules (backward compatibility) but older versions of node & npm will work with newer modules.
This is critical because our usage data shows that users have been very slow to move forward. In fact given the community growth rate, I my gut feeling is that much of the migration to v4+ has been mostly new users.
I would very much like any solution to work with npm@2 and Node 0.10 (or maaaybe 0.12). That is, the package.json should be setup such that if I want to make a multi-mode module w/ both es6 and es5, that an older npm can install the module and an older node load it.
As an aside: npm's support guarantees are broader than Node.js'. Currently npm only supports two major releases of npm itself. But it supports using them on versions of node going all the way back to 0.8. We're very much hoping to drop 0.8 support this year but inevitably I suspect we will always be supporting more versions of Node.js than Node.js does itself.
@iarna I totally agree with that sentiment and I see this proposal as best proposal yet to actually support this:
There's nothing intrinsically wrong with that, but pushing it into an already established ecosystem feels untenable to me.
I must be missing something… I'm gonna write through this... so you say:
So that implies, I guess, that the registry would return package metadata including something like this:
Or if the module ONLY supported es6 then it'd return:
Except I'm concerned that would set older versions of npm on fire, as they make lots of assumptions about shasum and tarball being set, so it wouldn't have an opportunity to give a reasonable error message. Sure it wasn't gonna work for them, but I don't want to introduce modules to the ecosystem that just by existing are guaranteed to break older npms.
And of course, if you swap that around and make
@iarna I see two different implementations but neither of them would touch the response of the npm server:
One would be using HTTP headers: The npm client requests it either with an additional header
Another implementation would be using a different endpoint. If the endpoint doesn't exist there would be an error from old servers. And npm would fallback to commonjs and the old endpoint.
Edit: Of course the old endpoint would still response with the old data. In order for old versions of npm to work as expected: In short this is just an extension of the current server.