Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use import instead of module #993

Closed
wants to merge 1 commit into from

Conversation

seanpdoyle
Copy link

  • export Helpers as default export in handlebars/compiler/base

* export Helpers as default export in `handlebars/compiler/base`
@seanpdoyle
Copy link
Author

@mmun would you mind merging this into your branch so we can move forward with emberjs/ember.js#10853

@stefanpenner
Copy link
Collaborator

import * as helpers from '...' may do the trick

@seanpdoyle
Copy link
Author

@stefanpenner

import * as Helpers from "./helpers";

results in

Warning: Line 4: Unexpected token * Use --force to continue.

The toolchain doesn't support that syntax

@kpdecker
Copy link
Collaborator

kpdecker commented Apr 9, 2015

Can you explain the reason for this change?

@kpdecker
Copy link
Collaborator

kpdecker commented Apr 9, 2015

Looks like this is trying to hack around #855 but is introducing more tech debt. Not really a fan of this but would love to hear the argument for it.

@seanpdoyle
Copy link
Author

@kpdecker you're right about that.

I'd certainly prefer to use import * as Helpers from "./helpers";.

This change is motivated by emberjs/ember.js#10853 (comment)

What would it take to support that syntax (given the changes in transpiler landscape since #855)

@stefanpenner
Copy link
Collaborator

import * as Helpers from "./helpers";

it is valid, we will need to upgrade the transpiler to support this (now or later)

@seanpdoyle
Copy link
Author

@kpdecker could we update https://github.com/kpdecker/es6-module-packager to use babel or a more recent es6ifyer?

@kpdecker
Copy link
Collaborator

That could be an option. es6-module-transpiler was a no go as it generated code that wouldn't run under IE. I don't have time to look into that now but I'd be glad to look at a pull request over there.

@stefanpenner
Copy link
Collaborator

Use the es6modules transpiler we have in the ember cli repo. It's Esperanto under the hood with flags enabled or enable able for es3 safety. It is also ultimately what ember core is currently build with

@seanpdoyle
Copy link
Author

@stefanpenner do you mean https://github.com/ember-cli/broccoli-es6modules?

Does that introduce a broccoli dependency to the build process (it appears we're currently using Grunt)?

@stefanpenner
Copy link
Collaborator

If you don't want to do that. Look at how it calls Esperanto under the hood and drop Esperanto in here. There may even be an appropriate plugin for this build system.

Just make sure to call Esperanto with the same flags ember-cli does. So es3 safety requirement is met.

kpdecker added a commit that referenced this pull request Apr 16, 2015
Converts the tool chain to use babel, eslint, and webpack vs. the previous proprietary solutions.

Additionally begins enforcing additional linting concerns as well as updates the code to reflect these rules.

Fixes #855
Fixes #993
@kpdecker
Copy link
Collaborator

Closing in favor of #998

@kpdecker kpdecker closed this Apr 16, 2015
@seanpdoyle
Copy link
Author

👏

@seanpdoyle seanpdoyle deleted the sd-use-import branch April 16, 2015 21:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants