Skip to content

Salsa: JS support for discovering and acquiring d.ts files #7179

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

Merged
merged 16 commits into from
Mar 2, 2016

Conversation

jramsay
Copy link
Member

@jramsay jramsay commented Feb 22, 2016

Salsa: JS support for discovering and acquiring d.ts files
(Isolating and continuing VS host changes from PR#6448)

(Mostly isolating VS host changes from PR#6448)
(Rules appear to be more strict - this was not caught on a local lint run)
}
}
else if (id === "include") {
options.include = isArray(jsonTypingOptions[id]) ? <string[]>jsonTypingOptions[id] : [];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to check that the array is actually composed only of strings (same on line 621 as well)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good idea - done

- Adding check to ensure TypingOptions 'include' and 'exclude' arrays are composed of strings
- Allow leading whitespace when removing comments from json
if (jsonDict.hasOwnProperty("dependencies")) {
mergeTypings(Object.keys(jsonDict.dependencies));
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per our meeting with ASP.NET (and for the general developer experience), didn't we want to search for devDependencies also?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes - thanks for the reminder! Will add those as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know how relevant it is here, but package.json has peerDependencies and optionalDependencies as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for drawing my attention to these. Doesn't seem too compelling to add them at this point but will consider adding them in future if we find the current dependencies are falling short.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem. Seemed like you'd want to cover those anyway, since there'll never be overlap in any of these fields and they are treated the same as regular dependencies on a local project. The only difference is when they're used as a sub-dependency dependencies.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks- included these dependencies as well

@@ -682,4 +688,28 @@ namespace ts {

return { options, errors };
}

function ConvertJsonOptionToStringArray(optionName: string, optionJson: any, errors: Diagnostic[], func?: (element: string) => string): string[] {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Function names begin with lower-case letters

@jramsay
Copy link
Member Author

jramsay commented Feb 26, 2016

👍

let safeList: Map<string>;
const notFoundTypingNames: string[] = [];

function tryParseJson(jsonPath: string, host: TypingResolutionHost): any {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i would use parseConfigFileTextToJson instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually readConfigFile is more appropriate.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

const tsdJsonPath = ts.combinePaths(cachePath, "tsd.json");
const tsdJsonDict = tryParseJson(tsdJsonPath, host);
if (tsdJsonDict) {
for (const notFoundTypingName of notFoundTypingNames) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we do this here? the host knows what files were not found. it can cache that and know not to search for them. we do not need to do this everytime.

- Adding ".json" file extension filter when retrieving json files from host and removoing filter
- simplify isTypingEnabled check
if (jsonTypingOptions) {
for (const id in jsonTypingOptions) {
if (id === "enableAutoDiscovery") {
if (typeof jsonTypingOptions[id] === "boolean") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

else push an error?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good - we're doing it if the other options are invalid so makes sense here as well.

- push error for invalid enableAutoDiscovery option
- adding interfaces for jsons
- removing updateNotFoundTypings
- node_modules normalize file names before using
- adding safeListPath to discoverTypings
enableAutoDiscovery?: boolean;
include?: string[];
exclude?: string[];
[option: string]: any;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

string[] | boolean instead of any

jramsay added 2 commits March 1, 2016 18:52
- Remove all references to Tsd.
Instead pass a map of package names to cached typing locations
These modules are already installed and are not expected to change

if (!safeList) {
const result = readConfigFile(safeListPath, (path: string) => host.readFile(path));
if (result.config) { safeList = result.config; }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit, new lines after {

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@mhegazy
Copy link
Contributor

mhegazy commented Mar 2, 2016

LGTM

- Renaming DiscoverTypingsSettings to DiscoverTypingsInfo to match host
jramsay added a commit that referenced this pull request Mar 2, 2016
Salsa: JS support for discovering and acquiring d.ts files
@jramsay jramsay merged commit de47fcc into master Mar 2, 2016
@@ -278,6 +278,14 @@ namespace ts {
return hasOwnProperty.call(map, key);
}

export function getKeys<T>(map: Map<T>): string[] {
const keys: string[] = [];
for (const key in map) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why no hasOwnProperty check here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should have. Thanks for pointing out.

@mhegazy mhegazy deleted the jsTypingForAcquireDts branch March 4, 2016 17:46
safeList = result.config;
}
else {
safeList = {};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is wrong. This will make an empty safeList, so nothing will pass the safety check. Should make it undefined instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

undefined means you will keep looking for it the next time. that does not help if it still does not exist. if the intent is to let all things pass through if there is no safe list, then we should have a sentinel value to indicate its absence.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should keep looking only if the safeListPath is provided. If it is not, we should stop trying. So this if block should have the condition of if (!safeList && safeListPath) With that I don't think we need a indicator value

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so keep trying if a path was provided, but the file does not exist? what value would that give you, it is most probably not going to be there.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking that we were passing in a safeListPath only when we are confident about the existence of the file. But what you said makes sense, we should not try again if not found no matter what. I'll make that change soon.

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants