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

Bug: Incorrect module resolution for "valid" ES2015 specifiers with hashes and/or search parameters #22689

Open
SMotaal opened this issue Mar 19, 2018 · 1 comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Domain: ES Modules The issue relates to import/export style module behavior Suggestion An idea for TypeScript

Comments

@SMotaal
Copy link

SMotaal commented Mar 19, 2018

TypeScript Version: 2.8.0-dev.20180315

Search Terms: moduleResolution "module path" hash

Code

import { x as x1 } from './x.m.js';  // Typed correctly on hover
import { x as x2 } from './x.m.js#esm' // Typed as "import x…" on hover

Expected behavior:

Since module specifiers are now standardized, whereby if given an absolute specifier (or a relative specifier and the absolute referrer) should always result in a validly constructed new URL(specifier, referrer) it is expected that when a specifier includes suffix aspects like hash and search, that those aspects would be excluded from the pathname that is being resolved.

The implications of hash and search in runtime is beyond the scope of TypeScript and should remain so unless somehow the environment is customized to behave different (plugins maybe). However, if at all relevant, the specs have stated that at runtime each unique "resolved" URL (including hash and search) evaluates to a single unique instance of the respective module. It is not expected that TypeScript would need to determine if and when a module is a specific unique instance. It is however expected that when suffix aspects are included in the specifier that TypeScript would still resolve it's types identically as it does for the pathname sans hash and search.

Sorry for the long text!

Actual behavior:

TypeScript does not resolve pathnames with hash or search parameters.

@DanielRosenwasser DanielRosenwasser added the Bug A bug in TypeScript label Mar 19, 2018
@DanielRosenwasser DanielRosenwasser added this to the Community milestone Mar 19, 2018
@DanielRosenwasser DanielRosenwasser added Help Wanted You can do this Effort: Moderate Requires experience with the TypeScript codebase, but feasible. Harder than "Effort: Casual". Domain: ES Modules The issue relates to import/export style module behavior labels Mar 19, 2018
@DanielRosenwasser DanielRosenwasser modified the milestones: Community, TypeScript 2.9 Mar 19, 2018
@DanielRosenwasser DanielRosenwasser removed Effort: Moderate Requires experience with the TypeScript codebase, but feasible. Harder than "Effort: Casual". Help Wanted You can do this labels Mar 19, 2018
@mhegazy mhegazy added Suggestion An idea for TypeScript and removed Bug A bug in TypeScript labels Mar 29, 2018
@weswigham weswigham added the Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature label Nov 6, 2018
@webappslove
Copy link

I don't understand how this issue is not a bug, as this issue brakes intellisense / go to definition! VS code isn't of much use without this feature :(

@mhegazy Shouldn't a valid practice (and with the goal of reducing dependencies on tools, e.g. manual cache busting), be supported, and shouldn't the lack of support be labeled as a bug!? Or do you think that everyone should just use tools until this "feature" (I would say correct behavior) is implemented?

Sorry if this is not very constructive, but the idea of switching IDE again just makes me cry...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Domain: ES Modules The issue relates to import/export style module behavior Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

5 participants