I'm sure thousands of other JS devs are feeling the pain I'm feeling. I love jumping to function definitions in .d.ts files while browsing code in VS Code.
However, sometimes instead of going to the .d.ts file, I'd like to jump to the raw JS code that is being hidden by the .d.ts file that sits in front of it.
Does anyone know how to optionally force a jump to the JS source code (if it exists) and not a TypeScript definition file.
Thanks!
EDIT: I am aware that this has been asked for to the VS Code team and will not be officially supported by them. I'm looking for some sort of hacky workaround (extension or otherwise) to get this to work.
Recently announced, VS Code Insiders (v1.67.2) supports a Go to Source Definition context menu option from right-clicking the symbol. This was committed 19-APR-2022.
This feature requires TypeScript 4.7:
Go To Source Definition
TypeScript 4.7 contains support for a new experimental editor command called Go To Source Definition. It’s similar to Go To Definition, but it never returns results inside declaration files. Instead, it tries to find corresponding implementation files (like .js or .ts files), and find definitions there — even if those files are normally shadowed by .d.ts files.
This comes in handy most often when you need to peek at the implementation of a function you’re importing from a library instead of its type declaration in a .d.ts file.
You can try this new command in the latest versions of Visual Studio Code. Note, though, that this functionality is still in preview, and there are some known limitations. In some cases TypeScript uses heuristics to guess which .js file corresponds to the given result of a definition, so these results might be inaccurate. Visual Studio Code also doesn’t yet indicate whether a result was a guess, but it’s something we’re collaborating on.
You can leave feedback about the feature, read about known limitations, or learn more at our dedicated feedback issue.
Delete the .d.ts file (temporarily)
This is obviously a super-crappy workaround, but it should work. By deleting the file you don't want to see, VSC will only have one place to take you: the file you do want to see.
When VSC takes you to the .d.ts file, right-click on the file tab and click "Copy Relative Path"
Open the VSC terminal and enter rm [PATH] (or del [PATH] for Windows)
leave the (now-deleted) .d.ts file tab open
Go back to the original file and try navigation again
if it doesn't work, you may need to reboot the TS server
Once you've seen the code you want to see, go back to the .d.ts file and save it
this will put the file back exactly as it was, which will probably be invisible to your source-control
if not, you may need to use your SCM to undo the deletion operation
Again, an awful hack. And I share your frustration that the VSC maintainers & community have no interest in this feature. Just bear in mind that their goal is to make their propriety technology displace all technology they don't own, so you will occasionally discover that they will refuse to help you as a web developer because they want you to be a Microsoft developer.
Related
Due to licensing issue, I will not be able to share the codes.
I was adding on validation to existing ones, and realized that even changing the existing validation's return value (a simple text msg) does not reflect on the browser. A quick summary, I was able to change any .html or .php file, just not .js files.
This project uses react too, not sure if this info helps.
Note that I have already cleared the cache of the browser many times as suggested by others.
May I know is there a mechanism where the creator can lock us out from changing the source code of .js files or a read-only code that don't accept addons/modification? If not, no methods to work around other than pointless refreshing.
Please note that the license only restricts the program to have n amount of users.
FYI- source code name is from IceHRM
Ok I have found the issue behind why .js changes are not reflected. The project uses Gulp to bundle the js files, therefore any change to the code must use the command gulp to "compile it" just like how .java has javac
side note, it rarely has to do with client or server cache
General tips are welcome. My specific situation is a React app, compiled with WebPack, with lots of files. If I want to move a file or folder within the project, is there a good way to do this such that references, such as import & require statements, update automatically?
Bonus points for solutions using Atom or VSCode.
NPM scripts will also work. Thanks.
I used a few text editors with plugins and IDE's during the years, this includes Atom, VSCode, SublimeText, etc. but keep coming back to Jetbrains products and one of the reason is the refactoring capabilities.
Jetbrains dedicated JavaScript IDE, Webstorm does it very well without any additional plugins or hacks.
All you need to do is drag and drop your file or folder to another location and all the relevant imports will be updated (make sure search for references is ticked in the confirmation pop up). This applies to both es6 import and/or common js require().
This is not all, you can rename variables, class, function names, whatever you like, just make sure you doing it by selecting the text, then right click then refactor and rename (you'll see in this menu you can do much more if you want)
Whenever you about to confirm your changes you can select the option in the pop-up that is "search in comments and strings" if you want which is really cool as you can keep your documentation up to date as well.
This official documentation goes more in deep, but generally if you do the above, it will be enough.
I guess if you don't feel confident enough, start up the server, with (create-react-app it will reload every time you make a change as hot reloading is built in) and if something goes wrong with your refactoring you will know it straight away.
Just fyi I am not associated with Jetbrains, I just like the product. Webstorm is not free (however it's very cheap) - go for the 30 day trial version if you don't wish to pay.
UPDATE:
Also note, this feature support both relative and absolute paths as well as any file extensions, so including .*scss etc.
Found a couple of plugins for VSCode. Personally, I haven't used them but they might work for you
https://github.com/cmstead/js-refactor
https://github.com/jakob101/RelativePathRefactor
VS Code has an option to update imports on file move or rename. This feature was enabled with the May 2018 Release. Whenever a file is moved, VS code detects and asks for confirmation to update the import references also.
Visual Studio Code - May 2018
You can control the prompting behavior with the
javascript.updateImportsOnFileMove.enabled and
typescript.updateImportsOnFileMove.enabled settings.
This usually updates the import statements, but it might not update
any strings variables/comments references to the moved files.
NOTE: It worked only for js/ts files. For other types, like scss file, it does not update the #imports.
Most editors/plugins do not support full fledged tracking and refactoring of move/rename actions for all file types, as it becomes more complex and ambiguous when relative paths, absolute paths are used in the same project.
To summarize, for moving a file or folder, there are two instances the references needs to be updated.
In the moved file itself, if any import is using a relative path
Other files which import the moved module/files
I do not think the first is supported in VS Code (and probably in other editors too). The second one is supported in VS Code, but only for js/ts file imports.
I wrote a JavaScript library, and I'm trying to understand how I can show the function parameters/definitions when a user hovers over them in VSCode (I see this in other libraries, and I dont notice anything special about them). Im sure its something simple but I just dont see how I would do it. Link to the project is here: https://github.com/isaacgr/jaysonic
I've tried adding jsdoc style comments around the class definitions, but in general I'm not sure what to try. I'd appreciate if someone could point me in the right direction.
An example would be what I see with JSON.parse
Visual Studio Code uses IntelliSense for autocompletions like the one you mentioned and in JavaScript they are based mainly on TypeScript definitions. If a project is already built using TypeScript, they may be generated and linked in the corresponding package.json-file using a "typings" or "types" property.
Alternatively (I haven't tested this approach though) existing JSDoc comments may be used to generate these TypeScript Definitions.
The TypeScript Community has furthermore (often manually) created separate Typescript-Definitions, which are available as npm packages called #types/name-of-the-package.
In your case the first approach of creating/generating a typings-file and linking it in your package.json is probably the best approach to achieve the desired result.
Btw, if you want to inspect such a typescript definitions file, press Ctrl (on Windows) and click on the JSON.parse method. This will show you the corresponding typescript definitions file called lib.es5.d.ts (which is embedded in vscode as it's part of the JavaScript language and therefore doesn't need to be installed)
Let's say I write a jQuery plugin and add it to my repository (Mercurial in my case). It's a single file, say jquery.plugin.js. I'm using BitBucket to manage this repository, and one of its features is a Downloads page. So, I add jquery.plugin.js as one of the downloads.
Now I want to make available a minified version of my plugin, but I'm not sure what the best practice is. I know that it should be available on the Downloads page as jquery.plugin.min.js, but should I also version control it each time I update it to reflect the unminified version?
The most obvious problem I see with version controlling the minified version is that I might forget to update it each time I make a change to the unminified version.
So, should I version control the minified file?
No, you should not need to keep generated minimized versions under source control.
We have had problems when adding generated files into source control (TFS), because of the way TFS sets local files to be read-only. Tools that generate files as part of the build process then have write access problems (this is probably not a problem with other version control systems).
But importantly, all the:
tools
scripts
source code
resources
third party libraries
and anything else you need to build, test and deploy your product should be under version control.
You should be able to check out a specific version from source control (by tag or revision number or the equivalent) and recreate the software exactly as it was at that point in time. Even on a 'fresh' machine.
The build should not be dependent on anything which is not under source control.
Scripts: build-scripts whether ant, make, MSBuild command files or whatever you are using, and any deployment scripts you may have need to be under version control - not just on the build machine.
Tools: this means the compilers, minimizers, test frameworks - everything you need for your build, test and deployment scripts to work - should be under source control. You need the exact version of those tools to be available to recreate to a point in time.
The book 'Continuous Delivery' taught me this lesson - I highly recommend it.
Although I believe this is a great idea - and stick to it as best as possible - there are some areas where I am not 100% sure. For example the operating system, the Java JDK, and the Continuous Integration tool (we are using Jenkins).
Do you practice Continuous Integration? It's a good way to test that you have all the above under control. If you have to do any manual installation on the Continuous Integration machine before it can build the software, something is probably wrong.
My simple rule of thumb:
Can this be automatically generated during a build process?
If yes, then it is a resource, not a source file. Do not check it in.
If no, then it is a source file. Check it in.
Here are the Sensible Rules for Repositories™ that I use for myself:
If a blob needs to be distributed as part of the source package in order to build it, use it, or test it from within the source tree, it should be under version control.
If an asset can be regenerated on demand from versioned sources, do that instead. If you can (GNU) make it, (Ruby) rake it, or just plain fake it, don't commit it to your repository.
You can split the difference with versioned symlinks, maintenance scripts, submodules, externals definitions, and so forth, but the results are generally unsatisfactory and error prone. Use them when you have to, and avoid them when you can.
This is definitely a situation where your mileage may vary, but the three Sensible Rules work well for me.
I've inherited an legacy project with tons of javascript files all over the place...
Is there a way to find which of those files are used inside pages?
Thanks in advance.
Use a debugging tool like YSlow!
http://developer.yahoo.com/yslow/
Such tools will usually point out redundant files and code.
You can inspect the website logs of past, say, one month, and locate all *.js files requested by browsers. The log might contain referrer page which makes things easier.
Something that I do very often for .asp files: find a good text editor that allows you to find text inside files/folders. Visual Studio .NET does an excellent job but I've tried and had success with Notepad++ too. Find all files that contain .js. If your text editor provides regular expressions support for searching (the aforementioned products do) this makes things even better. The regexp I use in VS is \.asp> (dot asp followed by a word boundary). The search results are often displayed in a window from where you can copy every thing and do some manual processing via more regex operations or copy the data to an excel file.
Macromedia Dreamweaver does an acceptable job if your website has some structure in it. There is a "Find broken links" command in Dreamweaver that generates a side report called "Orphaned files". The orphaned files report can tell you which js files are not referenced by any page. Then you can run the Dreamweaver's "Find" command (find in entire local website/find in folder) to double check each file one by one. I've tried that too. One thing to note is that Dreamweaver might not be able to detect cycles. E.g. if a file foo.js is used by bar.asp but bar.asp itself is not referenced by any other page, Dreamweaver will flag bar.asp as orphan but not foo.js. The recent version of Dreamweaver might do a better job.
You could create a script in a general purpose scripting language that runs through every html file in your project, checking their script tags. Or you could just do it manually, which may or may not save you some time depending on the size of your project.