Bugzilla – Full Text Bug Listing
| Summary: | Instead of creating .tern-project file when there is no information about the libs, create package.json | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Steve Northover <steve_northover> |
| Component: | JS Tools | Assignee: | Michael Rennie <Michael_Rennie> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P1 | CC: | curtis.windatt.public |
| Version: | unspecified | Flags: | curtis.windatt.public:
review+
|
| Target Milestone: | 14.0 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Steve Northover
The quickfix would only apply for libraries that are known to exist (there is either a definition for them or a tern plugin available or they are relative). This restriction exists because otherwise the problem does not go away after applying the fix - consider the following example:
var foo = require('foo');
'foo' will be tagged with "library is unknown...type information incomplete" warning (GOOD), but adding it to the package.json file will not fix the problem that we cannot find it. The only actual fix for that type of problem is to (1) add a definition, (2) get a tern plugin that knows about 'foo', (3) make it relative, (4) load it from node_modules.
I think this fix should be used alongside the tern-project file fix (not replace it).
Consider having a project with nothing in it but a single file that requires some lib and a .tern-project file (the setup from bug 512964). In that state, the user needs node to be running, but there are no configuration cues to have that happen, other than to warn them on the require, and offer the fix to the .tern-project file.
> adding it to the package.json file will not fix the problem that we cannot
Given a library 'foo', it can be either one we are about to write or one that we are going to reference. Whether we have type information about it or not should be a separate issue.
If we add a library to package.json, it is no longer unreferenced. In fact, later on, when an "npm install" is done, we'll get information about objects, functions and methods from node_modules.
If we offer to add the library to package.json and the user refuses, then we leave the warning in place. It will eventually get fixed when the library is defined.
None of these scenarios have anything to do with the type information, Tern or how well we offer code assist. What I am trying to get rid of is the case where the programmer references a library that does not exist.
(In reply to Steve Northover from comment #2) > > adding it to the package.json file will not fix the problem that we cannot > > Given a library 'foo', it can be either one we are about to write or one > that we are going to reference. Whether we have type information about it > or not should be a separate issue. > > If we add a library to package.json, it is no longer unreferenced. In fact, > later on, when an "npm install" is done, we'll get information about > objects, functions and methods from node_modules. > > If we offer to add the library to package.json and the user refuses, then we > leave the warning in place. It will eventually get fixed when the library > is defined. > > None of these scenarios have anything to do with the type information, Tern > or how well we offer code assist. What I am trying to get rid of is the > case where the programmer references a library that does not exist. We can easily suppress the warning if it appears in package.json - but like I mentioned, it will hide the fact that we don't know about it. So if the user ends up not defining, or does not ever install it, they get no support for it and will not know why. We have warning and info. Warning should be for "I can't find it" and info should be for "no type information". I'm wondering, what happens when the user gets info "no type information". What can they do? If we don't have the lib, they are SOL. Why are we informing them? Pushed in the first stage of support: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=c698af2faa0aded3c4387258ddfa5c3d11a183cf This first commit changes the fix behaviour for require'd libraries that have a tern plugin available. For example: var exp = require('express'); in a brand new project, you will see 'express' be tagged, with the fix, that will write the package.json file for you and auto-configure the environment so you can immediately begin working with express. Remainder of the fix: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=eea9f65932a294f89b0d04a0ebe35a33b3ba256a We now consider a library 'known' if it appears in package.json. The last part of the fix also makes the 'update package.json' fix available on the unknown-require rule (the rule that reports libraries are unknown and will have no type information. Curtis, please review. Minor issue, if you have require(''); The unknown-require rule marks a problem. Running the 'update package.json' fix adds 'undefined': 'latest' to the dependencies. The problem does not go away.
(In reply to Curtis Windatt from comment #7) > Minor issue, if you have require(''); The unknown-require rule marks a > problem. Running the 'update package.json' fix adds 'undefined': 'latest' to > the dependencies. The problem does not go away. Good catch. Pushed fix to: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=8acf80288f86f861498c959779a6f6bb14885fe7 I updated our linting rule to not check empty string names and / or non-string literals Thanks for adding the additional fix. Resolving as FIXED with my +1. |