Skip to content

baseURL #23

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

Closed
guybedford opened this issue Feb 24, 2015 · 10 comments
Closed

baseURL #23

guybedford opened this issue Feb 24, 2015 · 10 comments

Comments

@guybedford
Copy link

I know it's no longer strictly necessary, but consider running the browser loader in NodeJS for example - it can be useful to be able to set what the base path should be for normalizing unnormalized URLs.

It can also be nice to be able to do the following in the browser:

System.baseURL = '/js/';
System.import('blah');

And to be able to control that resolution. I think it's an important feature to keep here.

@guybedford
Copy link
Author

Also perhaps it's about time to call it baseURI rather?

@domenic
Copy link
Member

domenic commented Feb 24, 2015

I think this feature should be provided by custom loaders, not the built-in ones. Also, it's URL; URI is an obsolete term that doesn't correspond to anything in real software (i.e. all software just uses a single parser, known as the URL parser).

@guybedford
Copy link
Author

So we make it stick to document.baseURI / process.cwd(), and then if users want more than that they can add a custom resolve step?

@domenic
Copy link
Member

domenic commented Feb 24, 2015

Yeah. I don't think there should be a loader-specific way of customizing the base URL of a document. It would be weird to have that apply only to resources loaded through the loader (JS files, maybe HTML imports, what else?) but not others (CSS files, images, ...?)

@guybedford
Copy link
Author

Ok sure I can go with that - I guess it is specifically the NodeJS case that makes it necessary, and a custom resolve can make it work out there fine, or even chdir.

@justinbmeyer
Copy link

but not others (CSS files, images, ...?)

There is a way https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base

@domenic
Copy link
Member

domenic commented Mar 3, 2015

Yes, that was precisely my point, base element for some resources and loader baseURL for others is bananas.

@justinbmeyer
Copy link

Thinking about it some more ... is a design goal of this spec to work independent of environment? Outside of the browser, I could see how some "base" would be extremely important.

The Node case does make it necessary. How do you balance influencing factors of node vs browser vs Rhino vs Nashhorn etc?

@domenic
Copy link
Member

domenic commented Mar 3, 2015

My point of view is that base is an environment-specific thing, just like the actual mechanics of translating a URL or filename into a stream of bytes is an environment-specific thing. In node it is process.cwd() modifiable with process.chdir. In the browser it's document.baseURI modifiable with the <base> tag. In Rhino it's something else.

@caridy
Copy link
Contributor

caridy commented Mar 3, 2015

@justinbmeyer if you need some sort of custom base, you can rely on sites() to define the mapping for some of your files.

If we introduce baseURL, you have this big problem:

<script>
System.baseURL = '/static/whatever/';
System.import('path/to/foo.js');
</script>
<script src="path/to/foo.js" type="module"></script>

That's very confusing, because you break the reflection between the script type module and the Imperative api to load the exact same module since you have the ability to modify that value. Even more important, this breaks the mental model that developers have today when they think about fetching things over the network.

Essentially, we want to stick to the principle described by @domenic.

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

No branches or pull requests

4 participants