Bugzilla

I have something that is getting close to being finished, quick update on it:

You will be able to do relative imports now, the same pattern that is used in regular ES6 module imports. You can see this in action here: https://phabricator.services.mozilla.com/D113521

A couple of things I noticed while transitioning certdecoder to the new "module" form.

1) our reliance on requirejs will make some migrations quite frustrating. We might want a pattern that can be broadly applied to allow this. I used rollup to create requirejs like bundles in this case. However, since it was exporting for node's es6 modules, it needed some modification. This might be easier with source maps. 

2) We may want to not use .mjs -- it may make incremental transitions more difficult. At least, this was my experience when moving cert decoder. What might be the case is it ensures that we transition coherent chunks. That will probably mean we want to have good error messages. The other alternative is -- rather than Cu.import, we create a new funtion Cu.importModule.

2a) If we use mjs, any dependencies that we import from a vendor will also have to be renamed to be .mjs. This could potentially be a huge pain.

I have something that is getting close to being finished, quick update on it:

You will be able to do relative imports now, the same pattern that is used in regular ES6 module imports. You can see this in action here: https://phabricator.services.mozilla.com/D113521

A couple of things I noticed while transitioning certdecoder to the new "module" form.

1) our reliance on requirejs will make some migrations quite frustrating. We might want a pattern that can be broadly applied to allow this. I used rollup to create requirejs like bundles in this case. However, since it was exporting for node's es6 modules, it needed some modification. This might be easier with source maps. 

2) We may want to not use .mjs -- it may make incremental transitions more difficult. At least, this was my experience when moving cert decoder. What might be the case is it ensures that we transition coherent chunks. That will probably mean we want to have good error messages. The other alternative is -- rather than Cu.import, we create a new funtion Cu.importModule.

2a) If we use mjs, any dependencies that we import from a vendor will also have to be renamed to be .mjs. This could potentially be a huge pain. Jar files also make this a bit difficult, so we might want to say that we adopt a consistent way of loading libraries (such as asn1js & co in the example implementation)

I have something that is getting close to being finished, quick update on it:

You will be able to do relative imports now, the same pattern that is used in regular ES6 module imports. You can see this in action here: https://phabricator.services.mozilla.com/D113521

A couple of things I noticed while transitioning certdecoder to the new "module" form.

1) our reliance on requirejs will make some migrations quite frustrating. We might want a pattern that can be broadly applied to allow this. I used rollup to create requirejs like bundles in this case. However, since it was exporting for node's es6 modules, we probably want a different setting than what i used. 

2) We may want to not use .mjs -- it may make incremental transitions more difficult. At least, this was my experience when moving cert decoder. What might be the case is it ensures that we transition coherent chunks. That will probably mean we want to have good error messages. The other alternative is -- rather than Cu.import, we create a new funtion Cu.importModule.

2a) If we use mjs, any dependencies that we import from a vendor will also have to be renamed to be .mjs. This could potentially be a huge pain. Jar files also make this a bit difficult, so we might want to say that we adopt a consistent way of loading libraries (such as asn1js & co in the example implementation)

I have something that is getting close to being finished, quick update on it:

You will be able to do relative imports now, the same pattern that is used in regular ES6 module imports. You can see this in action here: https://phabricator.services.mozilla.com/D113521

A couple of things I noticed while transitioning certdecoder to the new "module" form.

1) our reliance on requirejs will make some migrations quite frustrating. We might want a pattern that can be broadly applied to allow this. I used rollup to create requirejs like bundles in this case. However, since it was exporting for node's es6 modules, we probably want a different setting than what i used. 

2) We may want to not use .mjs -- it may make incremental transitions more difficult. At least, this was my experience when moving cert decoder. What might be the case is it ensures that we transition coherent chunks. That will probably mean we want to have good error messages. The other alternative is -- rather than Cu.import, we create a new funtion Cu.importModule.

2a) If we use mjs, any dependencies that we import from a vendor will also have to be renamed to be .mjs. This could potentially be a huge pain. Jar files also make this a bit difficult, so we might want to say that we adopt a consistent way of loading libraries (such as asn1js & co in the example implementation)

2b) that said, mjs is kind of nice because we don't have any other signal that something is a script import