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

Custom naming systems #30

Closed
guybedford opened this issue Jun 18, 2015 · 4 comments
Closed

Custom naming systems #30

guybedford opened this issue Jun 18, 2015 · 4 comments

Comments

@guybedford
Copy link
Contributor

Really loving this project! The APIs are great to work with.

Just been playing around with hooking it in to SystemJS builder and I'm even defining a custom loader to manage everything in-memory which is great.

It would be nice to be able to use the same naming system as SystemJS without having to translate into file paths, so I'm trying to set both resolvePath and resolveExternal, but it seems the entry point still gets resolved to a path.

Would it be possible to have the above resolution run through the same hooks as above?

The ES specification defines module loading through two hooks:

  • HostNormalizeModuleName(ID, parentID)
  • HostGetSource(normalizedID)

It would be nice to maintain some consistency with this by allowing any naming system.

I know it's very much my use case, but let me know if it's a possibility.

@Rich-Harris
Copy link
Contributor

Great! This seems like it might be relevant to #25 (getting Rollup to work in a browser environment). If I understand you correctly, the goal is to replace this line with something that loosely equates to HostNormalizeModuleName (i.e. resolvePath, but where importer is undefined), so that a subsequent HostGetSource (a.k.a. load) operation can load the entry module in the absence of a filesystem. Is that right?

If so, that seems both doable and desirable.

@guybedford
Copy link
Contributor Author

Yes, exactly!

@Rich-Harris
Copy link
Contributor

Have to run now, but I've made a start on this in #31 - will pick it up soon, but in the meantime checking out that branch and npm linking it will allow you to try it out if needs be.

Rich-Harris added a commit that referenced this issue Jul 10, 2015
@Rich-Harris
Copy link
Contributor

Fixed as of 0.9.0. #31 for details. @guybedford let me know if this behaves as you expect!

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

2 participants