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

Build system #71

Closed
guybedford opened this issue Apr 12, 2014 · 8 comments
Closed

Build system #71

guybedford opened this issue Apr 12, 2014 · 8 comments

Comments

@guybedford
Copy link
Member

Moving the discussion from - #60 (comment).

@justinbmeyer yes you are right - a tracing extension does not execute code, while a build process does.

For this we need:

  • The ability to create new System loaders from the ES6 Module Loader
  • upgradeSystemLoader exposed on the loader for SystemJS when on the server.
  • Tracing extension

Note that my plan for handling builders through the load pipeline was to use conditional loading to have a separate plugin implementation on the server from the client. See the proposal at #9 (comment).

@justinbmeyer
Copy link
Contributor

What do you mean by conditional loading?

@justinbmeyer
Copy link
Contributor

Well, for a start, can I change upgradeSystemLoader to take a loader? With that small change, I can at least have a local version that exports this method while having "mergable" code with SystemJS.

@guybedford
Copy link
Member Author

See the proposal comment. Effectively I could write a plugin implementation like:

import './plugin-compiler-[env] | browser server';
// ..etc plugin..

Where the plugin compiler is a different module (plugin-compiler-browser.js or plugin-compiler-server.js depending on the environment. It's nicer than having a pluginBuilder, and makes things like internationalisation easier.

Cloning the System loader needs to take into account the default baseURL and paths config. But yes I agree with this in principle.

@justinbmeyer
Copy link
Contributor

I'm not sure about that ... It took me a minute of rereading to understand what you were suggesting. It wouldn't work for CanJS b/c my plugin compiler depends on can/util which itself depends on jQuery. I would have to copy that same trick to everything that loaded jQuery and everything that loaded things that loaded jQuery.

// in mustache
import 'mustacheCompiler'

// in mustache compiler
import 'can/util'

// in can/util
import 'jquery'

It's much better to say "jquery should be jquery-node" once and for all across the entire environment.

@justinbmeyer
Copy link
Contributor

Actually, I'd only have to copy it to anything that loaded jQuery, but that might be a lot of places. And I think the place to change a module is in config.

@guybedford
Copy link
Member Author

You could always do that with map config -

map: {
  jquery: 'jquery-[env] | browser server'
}

Or even just set the server version directly.

@guybedford
Copy link
Member Author

Actually no, conditionals should probably allow maps within them not vice versa.

@guybedford
Copy link
Member Author

I think we're pretty much there on this stuff. @justinbmeyer if you have comments or suggestions for the existing clone / loader APIs let me know (did you find a way around the previous issue where System was not being used properly).

The behaviour currently is that SystemJS picks up whatever System global is present, clones it, and then adds itself.

Calling System.noConflict() reverts this operation.

Does this handle everything we need?

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