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

Fix all the things #100

Open
wants to merge 48 commits into
base: master
Choose a base branch
from
Open

Fix all the things #100

wants to merge 48 commits into from

Conversation

stefanpenner
Copy link
Collaborator

@stefanpenner stefanpenner commented Sep 13, 2016

TL;DR this opens support (improved support, not quite perfect) for add-on and nested add-on usage.

The aim is to mangle imports/exports such that, each browserify bundle will uniquely identify each module by version. The associated importing module will also refer to that version. This will in-theory allow duplicate versions to co-exist. We would prefer this not to work, but shrug.... 🔥

  • Correctly resolve module versions.
  • Correctly Browserify each dependency.
  • Support multiple browserify/browserify.js imports.
  • Figure out what happens with the test tree.
  • Confirm works for nested imports.
  • Confirm works with engines.

  • POC
  • remove ember-cli 1.x support
  • CachingBrowserify
    • needs to pass-through all files. (StubGenerator now also rewrites importers)
    • use BroccoliPlugin (it needs to produce stable output) – this is optional, can happen later.
  • StubGenerator
    • safely rewrite app code imports (no regexp soup)
    • resolve npm dependency versions
  • EmberAddon

export default function() {
return flooring();
}
export { default } from 'outdated/utils/floor-type';
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is intentionally different than the addon module and should not re-export the module from the addon.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please coordinate before doing work on this branch. I am in the process of fixing these issues.

@stefanpenner
Copy link
Collaborator Author

@nathanhammond the tests have been updated to work with some known add-on limitations. There still exist further issues, but this now works around a resolving bug in ember-cli. So it is at-least closing to possibly working.

@stefanpenner
Copy link
Collaborator Author

Im heading to a meeting, and wont be looking at this for the next hour or so. My latest changes have been updated.

Please review the new lib structure, especially how in-repo modules dependencies are setup. Including that they declare their dependency on ember-browserify itself (this way ember browserify atleast runs for them).

There are more issues yet, although this is getting closer...

Rework tests, add reexports scenario.
@nathanhammond
Copy link
Collaborator

nathanhammond commented Sep 19, 2016

The next step on this, which I've started, is to switch to pushing a preprocessor into the parent addon and away from postprocessTree. See #109.

"ember-addon": {
"configPath": "tests/dummy/config",
"paths": [
"node_modules/modern",
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this not tests/dummy/lib/modern and tests/dumy/lib/outdated ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because by the time we actually need them in test they're present in node_modules because of the link behavior we use. Probably results in duplication, I need to think about this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we should be explicit, the indirection via symlink I think is unneeded.

@stefanpenner
Copy link
Collaborator Author

stefanpenner commented Sep 20, 2016

Some notes: browserify/browserify.js are being written (i believe):

  • for each bundle we expect 👍
  • for scenarios where no bundle exists 👎
  • for each bundle we expect, it seems we only get the last one 👎

We most likely need to address:

  • provide a non-colliding name to the file we intend to import

Something to consider:

  • 1 bundle per dependency, rather then 1 bundle per host
    • this would prevent us from having duplicate top level npm dependencies, but would mean per host bundles may not be as ideal.


Object.keys(imports).forEach(function(name) {
needsImportsReWritten = true;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to try comparing the imports object across runs?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ya, i'll fix in the work im about todo.

toTree: function(tree) {
var type = 'js';
var root = findRoot(instance);
var target = findTarget(instance);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is already via the add-on API, we should use that reference to it instead.

ext: 'js',
toTree: function(tree) {
var type = 'js';
var root = findRoot(instance);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't believe this is currently being used. We should remove it.

@nathanhammond
Copy link
Collaborator

Order of execution:

  1. dummy treeForAddon
  2. modern treeForAddon
  3. modern preprocessor
  4. outdated treeForAddon
  5. outdated preprocessor
  6. dummy treeForVendor
  7. modern treeForVendor
  8. outdated treeForVendor
  9. dummy preprocessor (app)
  10. dummy preprocessor (tests)

Can use treeForVendor to "correctly" provide Browserify modules for all things but the root. This will eliminate the need to use .import.

Looking into available workarounds for the root, whose preprocessors run far too late. Also investigating the degree of change to Ember CLI and risk in changing this behavior to match the nested story.

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.

2 participants