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

Watcher features still to implement #1789

Closed
4 tasks
guybedford opened this issue May 6, 2016 · 4 comments
Closed
4 tasks

Watcher features still to implement #1789

guybedford opened this issue May 6, 2016 · 4 comments

Comments

@guybedford
Copy link
Member

guybedford commented May 6, 2016

  • Package config file watching
  • jspm.config.js and jspm.browser.js file watching
  • symlink handling
  • watching when initial bundle has an error in it
@jonricaurte
Copy link

@guybedford I think symlink is a huge one when developing across apps that share common components in a separate repo.

@aluanhaddad
Copy link
Collaborator

aluanhaddad commented May 26, 2016

@guybedford Do you think extensibility hooks could be provided that would allow plugins to augment the watch process? For example, I think this could be useful for @frankwallis's plugin-typescript where one might want to watch for changes to tsconfig.json files. What do you guys think? Thanks!

@guybedford
Copy link
Member Author

We definitely need a way to handle dynamic hot reloading.

So if a module has:

import a from 'b';
export let x;
System.import('x').then(function(_x) {
  x = _x;
});

Currently we would only hot-reload b. We should be able to tell that x is a "dynamic dependency" of the module from a hot reloading perspective and to have changes in x trigger refreshes of the module as well.

In my opinion, loading typing files is a similar problem to the above as it is a dynamic import dependency.

One way we could support the above is by detecting "second arguments" to the System.import function. Instead of doing System.import('x') we do System.import('x', __moduleName) to use the contextually-normalized require. If this is done, then the import call itself can be hooked by say the hot reloading plugin, and it can assume that whenever there is a second argument, the parent module is that argument. That way, it can create an inferred dependency tree for the dynamic loads in the page.

Ideally we'd be able to use the same principles in a build. The static v dynamic nature becomes the same as the way CommonJS require is treated today, so there should be enough of an intersection to make that work and that is a priority.

Some ideas for the general direction here. Feedback / opinions further are welcome.

@aluanhaddad
Copy link
Collaborator

That sounds like a nice, general, and practical way to handle it. I'm still only getting started with jspm 17, as I have a lot of projects to convert from 16.32-34.
Thanks for the quick response!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants