We Keep Coding

What is a good file structure to have with Vite? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 months ago.
Improve this question
I am using Vite to easily run tailwind and other npm packages in my vanilla HTML and JavaScript.
This is what I have now: Current file structure
And this is my vite.config.js
const { resolve } = require("path");
const { defineConfig } = require("vite");
module.exports = defineConfig({
build: {
rollupOptions: {
input: {
main: resolve(__dirname, "index.html"),
about: resolve(__dirname, "about/index.html"),
},
},
},
});
Does anyone know a good file structure for a multi-page app, or know improvements to my current structure?

Personally, I like to separate my code by how it’s called, or type. For example, images and similar media type files may go in an “assets” directory. Same with CSS (or any styling methods), in a “styles” or similar directory, and same for JS. Whereas with JS, given that I generally use 99% JS in any given project, I get super modular.
My go-to style for JS (or just code in general honestly) is:
Utils directory for highly re-usable code (code that would be like a utility in lodash or similar utility libraries that are super general purpose, used for anything, anywhere)
Services directory for code that makes calls to external API’s or similar data fetching.
Components directory (more useful with React/Vue/etc., but could be useful still!
Pages (same as above)
And so on, with structure built on how the files actually get used, OR, the file type.
That being said, I’d personally check out how React people do it commonly, then aggregate that style with how Angular organizes its code. I’ve found a sweet spot between the two.

can I run a package that is installed on the "client" project from my own project?

I know this sounds like a weird question, let me try explaining it further with examples:
First of all, I'm trying to add some functionality to JSDoc in a simple library. Let's call it jsdoc-extra.
When a project includes my library, it should also have jsdoc installed. I have listed jsdoc as a dependency on my own library as well.
jsdoc-extra > package.json
{
[...]
"dependencies": {
[...]
"jsdoc": "^3.6.6",
[...]
}
}
And let's suppose a "sample" project is trying to use my library (this is what I actually have running for now, installed from the file)
{
[...]
"dependencies": {
"jsdoc": "^3.6.6",
"jsdoc-cov": "file:../jsdoc-cov",
"jsdoc-ts-utils": "^1.1.2"
}
}
From my jsdoc-extra code I can search and find the sample/node_modules/jsdoc/jsdoc.js that is installed on the "client" application (sample), or use my own jsdoc-extra/node_modules/jsdoc/jsdoc.js instead when the first one is not available. I can then execute it with spawn
So far so good. However:
The "client" (sample project in this case) might be using some plugins on their jsdoc setup, like you can see in the previous code snippet, I have ts-utils installed as an example.
So when I'm inside the sample project, and try running:
node_modules/jsdoc/jsdoc-extra.js -c jsdoc.json
(jsdoc.json is the standard jsdoc config file that I just pass through to it)
I get this kind of errors:
(node:3961) UnhandledPromiseRejectionWarning: Error: ERROR: Unable to find the plugin "jsdoc-ts-utils"
It seems my app (jsdoc-extra) cannot use jsdoc-ts-utils that is installed on the client (sample) project, even when I run sample's own installed jsdoc.
I want to be able to execute it like this so the "client" project can execute jsdoc-extra without extra jsdoc configuration, it will use whatever it's already using for regular jsdoc operations.
I'm beginning to think that my best options is to actually write a jsdoc plugin...
I know this is a lot, and probably confusing, I'll gladly provide more info if you think it's necessary. Thanks!

I decided to close this and instead just write a jsdoc plugin. It's the easier way to hack into the data it generates to do what I want. My extra functionality will be tied in with the doc generation, which is not ideal, but I'll deal with it...

mocha.opts deprecated, how to migrate to package.json?

I'm working on a massive project and since last week I updated mocha, Now we are getting warning:
DeprecationWarning: Configuration via mocha.opts is DEPRECATED and
will be removed from a future version of Mocha. Use RC files or
package.json instead.
I want to migrate the options to package.json but there is no good migration guide. all posts on GitHub with similar questions are all answered "see the docs". But the docs doesn't show how to transfer one option from mocha.opts to package.json, there is no information on how it should be formatted. Only thing I can find is that the "spec" property is the pattern for files to run. Nothing else seems implicit to me.
Our mocha.opts file:
--reporter dot
--require test/mocha.main
--recursive src/**/*.test.js
--grep #slow --invert
My attempt which doesn't work:
"mocha": {
"reporter": "dot",
"require": "test/mocha.main",
"spec": "src/**/*.test.js",
"grep": "#slow --invert"
},
Please explain how I should format this configuration block in order to achieve samme behaviour as when using the options from the above mocha.opts

I too had some difficulties finding the exact solution for migrating to new standards and could finally resolve those. I hope I'm not too late and I can still help you.
So first thing, you would need a new config file to replace mocha.opts. Mocha now offers quite some variations of file formats which can be used for it. You can find these here in their GIT. I took .mocharc.json and will be using it for further examples. Although adding it didn't change anything just the way it shows no effect for you too.
The catch was to point mocha test script to this config file in package.json. Provide --config flag in the test script in the scripts section in your package.json like below.
"scripts": {
"test": "mocha --config=test/.mocharc.json --node-env=test --exit",
"start": "node server"
}
Now you can update your configs in the .mocharc.json file and they should reflect correctly. Below is an example of it.
{
"diff": true,
"extension": ["js"],
"package": "../package.json",
"reporter": "spec",
"slow": 1500,
"timeout": 20000,
"recursive": true,
"file": ["test/utils/helpers.js", "test/utils/authorizer.js"],
"ui": "bdd",
"watch-files": ["lib/**/*.js", "test/**/*.js"],
"watch-ignore": ["lib/vendor"]
}
I'm using file property to define which files should go first as they need to be executed first. They will be executed in the order you provide them in the file array. Another property you can play around is slow whose value defines whether mocha consider the time taken to execute any test case as slow or not.

Check out this link to see the new format of the options file for mocha:
https://github.com/mochajs/mocha/blob/master/example/config/.mocharc.yml
Basically you need a .mocharc.yml, or .mocharc.json, (there are a couple more formats) to set the mocha configurations. I came to this POST hoping to find an answer too. Hope this is helpful for you!

I ended up getting the package.json working by using an array instead of the string literals you did.
ex:
"mocha": {
"require": ["tsconfig/register"]
}
Might be worth a try!

Seems like mocha won't check the package.json for config by default so you need to pass --package package.json.

/* This example illustrates how to configure mocha globally
*1. add the 'mocharch.json' to link mocha to the 'package.json' like so:
*/
{
"package": "./package.json"
}
/* 2. in the 'package.json' add: */
"mocha": {
"recursive": "true"
}

The answer by Rathore is great, but I just wanted to point out that if you just add the .mocharc.json file to your base directory, you don't need to specify "--config=test/.mocharc.json" in your package.json, it just finds it automatically.

you can create .mocharc.json in project root folder.
{
"spec": "src/tests/**/*.ts",
"require": "ts-node/register"
}
in package.json add mocha property.
"mocha": {
"spec": ["src/tests/**/*.ts"],
"require": ["ts-node/register"]
}
js project change file name.

How to make Visual Studio Code check entire project for errors?

I'm using VS Code for TypeScript/JavaScript development. When I open a file it will check that file for errors. The problem is if I'm refactoring (like I move some shared code to a new location or change a name) it won't show me the errors this caused until I open the file with the problem. ...so if I want to do extensive refactoring I have to open every file just to make it scan the file for errors.
How can I make VS Code scan the whole project for errors without having to open each file one by one manually?

VS Code (v1.44) has an experimental feature, that allows project wide error reporting in TS. Try it out:
// put this line in settings.json
"typescript.tsserver.experimental.enableProjectDiagnostics": true

Figured it out. Note this answer is specific to TypeScript, which is what I am using. Here it is:
Make sure typescript is installed globally (I just had mine installed locally apparently):
npm install -g typescript
Then in VS Code press Shift+Ctrl+B. If you don't have a task runner set up it will ask what you want. I selected typescript and the tasks.json file will look like this:
{
"version": "0.1.0",
"command": "tsc",
"isShellCommand": true,
"args": ["-p", "."],
"showOutput": "silent",
"problemMatcher": "$tsc"
}
Then pressing Shift+Ctrl+B (or Shift+Command+B in macOS) will check the entire project for problems and they will be reported in your "problems" panel.

If you don't want to install TypeScript globally, you can do the following:
Install TypeScript locally on the project, that is yarn add --dev typescript or npm install --save-dev typescript.
Add a check-types run script to ./package.json. --noEmit means that the compiler will won't generate any JavaScript files.
{
"scripts": {
"check-types": "tsc --noEmit"
}
}
Let VSCode know about the run script in /.vscode/tasks.json.
{
"version": "2.0.0",
"tasks": [
{
"type": "npm",
"script": "check-types",
"problemMatcher": [
"$tsc"
]
}
]
}
To run the tasks hit the F1 key and select 'Run Task', and then 'npm: check-types'.
If you add the following lines to the task, pressing Ctrl+B will run it.
"group": {
"kind": "build",
"isDefault": true
}

For the most recent version of tasks.json this is the correct json, following deprecations in version 1.14. Create this as /.vscode/tasks.json
{
"version": "2.0.0",
"command": "tsc",
"type": "shell",
"args": [
"-p",
"."
],
"presentation": {
"reveal": "silent"
},
"problemMatcher": "$tsc"
}

Once you have open your project in vs code, open the vs code terminal and run:
node_modules/.bin/tsc --noEmit

Go to View menu > Extensions and make sure the Microsoft VS Code ESLint extension is installed.
In Settings, search for "ESLint > Lint Task: Enable", and enable that setting (docs).
In the Terminal menu, choose Run Task… > eslint: lint whole folder.

UPDATE.
My answer below does not answer the original question, but if you're like me and have found this thread searching for how to turn on // #ts-check project-wide in VSCode so that you don't need to add // #ts-check to every file then my answer below is what you need. I have searched and searched and kept getting this thread as my top result so hopefully this helps others as well
I'm on vscode version 1.52.1 and the answer is so simple and right on the vscode website:
https://code.visualstudio.com/docs/nodejs/working-with-javascript#_type-checking-javascript
scroll down to the "Using jsconfig or tsconfig" section
Add a jsconfig.json in your project root and add "checkJs": true
{
"compilerOptions": {
"checkJs": true
},
"exclude": ["node_modules", "**/node_modules/*"]
}
You might need to restart vscode once you add it in

None of the other solutions worked fully for me. Here's a tasks.json that does, working with vscode 1.67+. On Linux etc. set command to tsc, on Windows be sure to run tsc.cmd as tsc alone will attempt to run the bash script and produce the following error:
The terminal process failed to launch: A native exception occurred during launch (Cannot create process, error code: 193)
"revealProblems": "always" in the presentation section shows the Problems panel on completion.
{
"version": "2.0.0",
"tasks": [
{
"label": "tsc: error check project",
"command": "tsc.cmd",
"args": [
"-p",
".",
"--noEmit"
],
"isBackground": false,
"problemMatcher": "$tsc",
"group": {
"kind": "build",
"isDefault": true
},
"presentation": {
"revealProblems": "always",
}
}
]
}

Edit: Since updating to 1.52.0 this no longer works. It will instead replace the current project files with what you selected...
===
I've tried every solution I can find and I think it's safe to say the answer is: You can't*
The best I've found is still technically opening each file manually, but at least it's not one-by-one:
You can't drag/drop a directory but you can select multiple files (including directories) and drag/drop. The directories will be ignored and any files you had selected will be opened in tabs.
Next, you need to give each tab focus so it triggers eslint to run. (Holding down the next tab keyboard shortcut works.)
This is terrible and I beg someone to prove me wrong.
*I haven't found a way that works as well as opening files manually. Each method -- experimental vscode feature and tsc task -- has its own set of drawbacks. The vscode feature is clearly the solution but without a way to ignore node_modules, etc. it's too painful to use.

NPM script needs exact file name

Normally when pointing node to a folder, if there is an index.js file there, we don't need to specify it.
I installed an NPM dependency that I am working on, npm install --save-dev suman.
Suman has an index.js file at the root of its NPM project.
In my NPM scripts for a project that depends on suman, I have this:
"scripts": {
"test": "node node_modules/suman/index.js --rnr test"
}
The above works!
But this doesn't work:
"scripts": {
"test": "node node_modules/suman --rnr test"
}
Why is this?
Perhaps the answer is obvious - the require function in node is capable of such behavior, but node itself is not.

Since the library has a bin in its package.json, you don't need to explicitly provide the path to it. Just run node suman --rnr test and npm will take care of using the correct file.
When you install a dependency with a binary in your node project, npm creates a symlink to that file in ./node_modules/.bin and uses those when running npm scripts.

You need to add the correct path:
"scripts": {
"test": "node ./node_modules/suman --rnr test"
}
Notice the ./
Update:
After thinking about this a bit more, It may not be this easy. But take a look at this link: https://docs.npmjs.com/misc/scripts - #elssar seems to be on the right track.

Sorry that I can't include my thoughts simply as a comment rather than as an answer but I don't yet have enough reputation points to comment. However, perhaps the following is relevant:
If, in your problem, the node command finds the appropriate index.js the same way as is shown in the node documentation for modules, then the documented look-up routine will find a different index.js before finding the one that (I think) you want. Specifically, before trying node_modules/suman/index.js (which is the one you want), node will look to see if the "main" field in node_modules/suman/package.json exists. In suman, it does, and it references lib/index.js (i.e. node_modules/suman/lib/index.js) which is different than the one you want. Is that relevant?
UPDATE: Just to clarify my answer with more generic language...
Your original question is a valid one because, in the absence of any other complications, if dir/index.js exists, then both of the following
node dir/index.js ...
node dir ...
should refer to the same (default) file, i.e. dir/index.js. Thus it is reasonable to be confused when those two commands give different results. The explanation is that there IS a complication: the dir/package.json file effectively redirects node dir ... to use a non-default file. This is because the "main" property refers to dir/some/other/file.js. The rules of precedence specify that, if only a directory name is used, this other file will be used before the default. Thus, you are forced to continue to use the longer and more explicit "working" command from your question.