Differences between 2.07 and 2.04 about form-urlencoded HOT 9 CLOSED

@avilaj the problem stems from changes discussed in this issue #17

To my knowledge es6 import is incompatible with commonjs and it is becoming more common to upgrade to es6 and expect the user to import default when using commonjs. What do you think?

It would be possible to generate a script that does not export default, but I've noticed other projects are beginning to require import default, for example infernojs works this way now.

Please share your thoughts. I'd like the script to work in a straightforward way for as many people as possible.

from form-urlencoded.

cc @AndrewDebens @jumper423

I apologize to bother you. Please chime in if you have any suggestions or ideas.

from form-urlencoded.

I'm not currently aware of any clean solution to this, but there are a few approaches.

The cleanest I can come up with is to revert the offending pull request, and use node method of module.exports, supporting commonJS. This forces an ES6 consumer to use a transpiler to check for the __esModule flag presence to correct for default, or lack of, exports, but honestly who isn't using something like babel these days.

Now this does mean that for peak performance a typescript user would have to compile their code first to ES6 and then transpile it down further using babel (or equivalent), but they should really not use typescript to go further back than ES6 anyway, as any further and you loose that juicy tree shaking. And if you really don't care about tree shaking then you can use the esModuleInterop flag in the tsconfig.

I do agree that people are moving towards ES6, and rightly so, but this was a breaking change, and hence should have been done as a major version update (My bad). And maybe also have a lib/ folder that would have the support for commJS exports, just for that supper safeness?

from form-urlencoded.

@AndrewDebens thanks. Some tools I use such as vscode seem to work better with es6.

The only way I know of to "tell" the build tool which script to use (ES6-version or CommonJS-version) is by using the "module" property and I'm not sure if all build tools will use that or only rollup. If we generated a CommonJS version I don't know how to guarantee it will be used for CommonJS environments only...

I imagine it will be easier to add a readme note to use require('form-urlencoded').default with CommonJS. @avilaj do you think that would be sufficient?

edit, added a commonjs note to the README

from form-urlencoded.

Thanks @iambumblehead & @AndrewDebens for your thorough explanations, my current issue is that i'm using just plain node. I wasn't aware of such incompatibilities with es6 and commonjs modules. Most of the time webpack takes care of those issues, but this time I'm not using it.
I have solved it by using require('form-urlencoded').default.

My intention was to report a breaking change inside the same minor version. I would expect such architectural changes to be on a new major release or be notifed of deprecation in advance, in the current one. But it might have been planned for version 2 to be released with this new export api. If such outcome was not the intention I would go with reverting the offending pull request, and implementing later the breaking change, in my opinion.

from form-urlencoded.

@avilaj I've been doing this all wrong --I'll follow your recommendation.

from form-urlencoded.

@avilaj I created two tags, 1.0.9 and 2.0.0 and published each to npm.

1.0.9 uses the commonjs module.exports,
2.0.0 uses the es6 export default.

Does it seem OK to you?

from form-urlencoded.

from form-urlencoded.

@avilaj it would be awesome if you would confirm and close this :)

from form-urlencoded.