doc: add MANIFESTO.md

[MylesBorins]

I wanted to take a shot at finding some core principles that our
group can rally behind. Please feel free to push a commit to add
your name to the signatories. Also please comment if anything doesn't
work for you.

[jdalton]

The Node.js implementation of ESModules must have the following features:

• Compliant to ecma262. It is important to follow the standard. If we need changes in the standard we should attempt to accomplish them at tc39.

The current approach of going to standards bodies with tiny asks without broader context, or working implementations with a fully realized vision, hasn't worked out well. I'd like to see that changed to implement first and then go to standards bodies with the asks that shake out of implementation.

[bmeck]

@jdalton thats what the staging system now encourages during stage 3. Is there any specific task you would like to see here? Do we need to change the text in this document somehow to clarify? I don't think we can really make much in terms of breaking spec changes to existing things from my experiences and given that browsers have started shipping ESM unflagged. As long as that is kept represented I think changing text would be fine, but am unsure on what is exactly being asked.

[jdalton]

Do we need to change the text in this document somehow to clarify?

Yes. If we focus on developer experience and scenarios then spec changes will fall out of that naturally. While we should try to stay in the bounds of today's spec we shouldn't be shackled to it. We should have to freedom to implement to fulfill the dev experience/scenario and if spec asks emerge we can take them to the standards bodies with fully realized implementations.

[devsnek]

nothing in the current manifesto says we can't do that, all it says is that our final implementation must be spec compliant and that if we want to change stuff we should work to do that

[jdalton]

This

Compliant to ecma262.

to

Compliant to ecma262 as possible.

which I think fits the spirit a bit more.

[bmeck]

@jdalton I really want to keep strict compliance. We can iterate and implement something that isn't to spec and seek spec changes, but would want to remove anything that isn't able to be compliant before releasing a final implementation. I think implementing something that pushes things outside of the spec or requires backwards compatible changes is fine, but not something we should ship if we cannot change the spec. As long as we agree that the final implementation should be spec complaint, I think going to the committee with a full implementation that is not spec compliant to request changes is fine. We would still need to get browsers on the committee to agree to changes, which has been the problem in the past.

[ps] I've said other places I'm also fine shipping something that isn't spec compliant as long as we don't try to label it as ESM compliant.

[jdalton]

As long as we agree that the final implementation should be spec complaint, I think going to the committee with a full implementation that is not spec compliant to request changes is fine.

Node should be able to put its user experiences/scenarios first and should not be roadblocked by other parties. Node should try to the best of its ability to work within existing constraints and with the respective standards bodies but if push comes to shove Node's user experiences/scenarios should win.

[robpalme]

Compliant to ecma262 as possible.

It would be a bit odd to have a manifesto that starts by recognising an existential risk to JavaScript then state that we might need to violate the specification of that language.

[jkrems]

Node's user experiences/scenarios should win.

While I do agree in general (we should focus on trying to solve our user's problems), I don't think it's good to imply that we're matching the spec "just because". We're trying to match the spec because we assume that it is in the interest of users that their code is likely to work outside of node and be compatible with future iterations of the language.

[jdalton]

I don't think anyone stated "just because". I'm aware that following the spec is a good thing for users too but it's not the sole driving force of all the things. I think "as possible" captures that spirit, without being overly asterisked, while allowing Node to deliver its dev scenarios/experiences to the fullest.

[MylesBorins]

One thing I think is worth mentioning... nothing that is currently considered contentious is due to the spec... if anything it is the things that are not specified that we are having the hardest time reaching consensus on (module specifier resolution).

There is nothing saying that our implementation cannot be a superset and still be compliant. For example, while the tc39 decided against using an in band identifiers such as use module, there is nothing stopping core from implementing it, aside from a lack of consensus.

[MylesBorins]

I removed all the implementation details which had the amazing effect of solving all of the above conflict. it also felt like picking a subset was a good way to stay true to the copy people have already signed.

That being said please let me know if you think I should start the signature from scratch

[jdalton]

I don't think signatures are needed.
We're already members of the WG.

It seems very cliquey.

[MylesBorins]

@jdalton that was definitely not the intent. I simply didn't want to land a document like this without fill buy in from the team. (Not just lazy consensus)

This was an attempted to align everyone, and if I'm missing the mark on that perhaps we should close this

[MylesBorins]

I'm going to close this. I think it was a good exercise but unsure that we should land it.

Let me know if I should reopen

[devsnek]

if we can't decide what to put in a super abstracted manifesto we certainly won't get any real work done. we should work to finish and merge this imo

[robpalme]

I agree with Gus. Surely there is some broad statement of intent that we all believe in. This document is a useful assertion of that. If new or existing members disagree with the content and are encouraged to explain why, that's helpful.

…

On Wed, 21 Mar 2018, 12:49 Gus Caplan, ***@***.***> wrote: if we can't decide what to put in a super abstracted manifesto we certainly won't get any real work done. we should work to finish and merge this imo — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#45 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGni9ajQE5sLPAuyLCIWE9OeJ8lAGcs_ks5tgkw_gaJpZM4Sfcog> .

[ljharb]

We should definitely reopen it, and merge it.

Being a member of the WG signifies merely that you're interested in advancing, blocking, discussing, etc, use cases and implementations.

Signing a letter of intent signifies you're part of a united front of common principles we can all adhere to.