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

Importing shared ES6 modules futuristically #639

Open
davidgovea opened this issue Jun 5, 2014 · 2 comments
Open

Importing shared ES6 modules futuristically #639

davidgovea opened this issue Jun 5, 2014 · 2 comments

Comments

@davidgovea
Copy link

This is more of a question/discussion than an issue. Close this & redirect me if appropriate!

First let me just say thank you to the maintainers - we're using EAK for several apps at work and it has inarguably reduced code debt. It's been also nice that we can keep all our custom tasks/config out of the Gruntfile and tasks/options. We've been able to perform smooth continual updates of eak, due to this.

However, the addition of validate-imports took some getting used to, and it seems to be a pain point for some others, at least. Specifically - adding new imports to the validate-imports whitelist: myModule: ["default"]

I get it though - the import validation is good (helpful!), ES6 is "future-proof"™, and the CommonJS-style import format is great.
For now, named-amd is working nicely for bringing in external modules via index.html.

Say I have 2 Ember apps, and I want to share a module between them. Perhaps share my utils/ajax or even some models, controllers, and mixins?
We've investigated POD structure, symbolic linking of files into app/, creating manifests of shared folders for Grunt to copy into app/, and others. We just want to share!

In the future, I'll be all like..
app/routes/index.js

import IndexRoute from 'shared/routes/index';
export default IndexRoute;
// Off to non-whitelist-editing-type things!

This way we also keep the "everything-as-one-file" principle.

Hacky future, today

Needing something today, I hacked together an import-shared task that runs right before validate-imports. It takes a configuration object of modulePrefix: modulePath pairs.

{
  'shared': 'submodule/shared-modules',
  'eak2': '/home/dev/ember-app-kit-2/app'
}

The import-shared task does several things:

  • Parse all app/ files with esprima (just like validate-imports)
  • If an import declaration is found with a namespace present in config,
    • the task live-patches the several grunt configs:
      • adds module name to validate-options whitelist
      • adds file to the copy:javascriptToTmp (EAK task) file list
  • The task also adds entries in the transpile and watch tasks.
    This way, your ES6 modules can be resolved to files, copied into the tmp/ directory, and transpiled at the same time as the rest of the app.

I can post up an example fork, or a proper PR with the new task in tasks/options, but I wanted to get some input here first. How are people solving this, and where is ember headed?

Thanks!

@davidgovea
Copy link
Author

Also, I'll add - we are using symbolic links for bringing in shared templates. Probably not the best method in terms of the future of ember (windows issues?), but it was quicker than messing with the emberTemplates task..
need to keep a manifest of shared templates somewhere, so might as well be in a file-like way.

@patrickod
Copy link

I would love to see an example fork with this functionality as it's something I'm starting to think about doing. I'd love to be able to have code shared between 2 ember apps easily.

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

No branches or pull requests

2 participants