search

esnext / es6-module-transpiler

Tomorrow’s JavaScript module syntax today
http://esnext.github.io/es6-module-transpiler/
Other
1.21k stars 85 forks source link

Added ability to disable "use strict". #123

Closed simonexmachina closed 10 years ago

simonexmachina commented 10 years ago

I'd still like to be able to use this transpiler with a legacy codebase which has some files that aren't strict. I know that the legacy modules won't work in ES6 tags but I'm okay with that.

rwaldron commented 10 years ago

I strongly recommend not deviating from the spec. Module code is strict by default, if this project wants to accept such a change it should change it's name. If your "legacy" code is non-strict, it is a bug itself and should be fixed. This isn't an opinion.

domenic commented 10 years ago

Legacy files that aren't strict and can't be made strict should not be upgraded to ES6. It is that simple. If you have files that can't be upgraded to strict then you also have files that can't be upgraded to ES6 modules---that's not an opinion, it's just a fact.

eventualbuddha commented 10 years ago

While I agree with @rwaldron and @domenic, I do want to understand your use case instead of dismissing it. Are you dealing with "legacy" first-party code or "legacy" third-party code? If the latter, I would recommend not attempting to wrap such code in ES6 modules. If the former, can you provide some context?

simonexmachina commented 10 years ago

I've just started on a project with a pretty large codebase that's not strict and doesn't have any loader or dependency management - just a lot of ordered script tags in the html file. This quote obviously sucks, so we're going to add a module loader and I'd like to use modern syntax. I can't personally see any downside to adding this option, but obviously I can use another module loader for the old code.

rwaldron commented 10 years ago

@aexmachina I assume you've already attempted to run all of that code in strict mode?

eventualbuddha commented 10 years ago

@aexmachina I haven't personally found that many things that don't work in strict mode, but I understand your desire to gradually transition. I still agree with @domenic, however. Having a not-really-ES6-modules configuration defeats much of the purpose of this project, which is to be able to use your ES6 module code as-is and have it work in ES6-capable environments. Introducing a disconnect there is likely to introduce bugs.

This project is already non-compliant in a number of ways, such as bindings, and my goal is to make it more compliant, not less compliant. I suggest that if you want to use a module system on your non-strict code that you should use CommonJS or AMD, which will give you a stepping stone to later update to ES6 modules.

simonexmachina commented 10 years ago

Okay, thanks for the feedback guys. We'll just use my fork for the moment and either make the code strict or switch to another loader such as requireJS.

For anybody interested my fork is called es6-grubby-module-transpiler ;) and there's a Broccoli plugin here.