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.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 16 hours ago.
This post was edited and submitted for review 14 hours ago.
Improve this question
Sorry that I am very new to coding and programming. A lot of stuffs I still don't understand.
I'm having a React code with all the frontends and I wanted to import a module from an auto-generated js file that module.exports an async function. I need the file to perform some calculations and return some values.
However, I keep getting error like this:
Uncaught SyntaxError: The requested module '/#fs/home/zk/solidity/safehome/circuits/main_js/witness_calculator.js' does not provide an export named 'default'
How do I solve this?
Even if I changed the code using { instance } in import still comes up with the same error, just that in this time it says import named "instance" is not found. If I change module.exports in the auto-generated js file to export default, I will have another errors.
code is something like this in js file contains the class:
import builder from "../../../circuits/main_js/witness_calculator.js";
and this is the exports from another js file:
module.exports = async function builder(code, options) {...}
How to reproduce the error:
Clone the below link, checkout "zkedit" branch, cd into "client" folder and npm run dev.
https://github.com/honghan87/safehome
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 months ago.
Improve this question
I'm struggling with the production build of a typescript monorepo. The company I'm working for has a mono repository with multiple APIs (nestJS) and few common libraries (mainly typescript source code built using tsc) which I can't sadly share here.
The APIs are runnable using nest start and we can also access to the #nestjs/swagger deployed within the APIs without any problem. Until few weeks ago we were building the production artefact using nest build --webpack with the following webpack configuration :
const path = require("path");
const webpack = require("webpack");
module.exports = function (options) {
return {
...options,
mode: "production",
target: "node",
node: {
__dirname: false,
__filename: false
},
entry: "./src/main.ts",
output: {
path: path.resolve(__dirname, "build"),
filename: "main.js",
clean: true
},
externals: [...options.externals, "fastify-swagger"],
module: {
...options.modules,
rules: [
{
test: /\.(t|j)sx?$/,
exclude: /node_modules/,
use: {
loader: "ts-loader",
options: {
transpileOnly: true,
projectReferences: true
}
}
}
]
},
plugins: [
...options.plugins,
new webpack.IgnorePlugin({
checkResource(resource) {
const lazyImports = [
"#nestjs/microservices",
"#nestjs/microservices/microservices-module",
"#nestjs/websockets",
"#nestjs/websockets/socket-module",
"#nestjs/platform-express",
"#nestjs/swagger",
"#nestjs/mapped-types"
];
if (!lazyImports.includes(resource)) {
return false;
}
try {
require.resolve(resource);
} catch (err) {
return true;
}
return false;
}
})
]
};
};
We are not really sure of this configuration, it let use bundle our APIs as one file per API containing all the dependencies (which, based on my numerous researchs, is a bad pattern). Our usage of the IgnorePlugin is quite hazardous and conflict-driven.
Until now it was working fine but we are now unable to access the swagger page provided by #nestjs/swagger and configured within our APIs. The route exists but leads to a white page (the json containing the API description is loaded but every swagger static resource loading returns a 404).
I thought about a swagger static ressource copy but it seems to be a bad pattern. Moreover we do not have a node_modules since we are using Yarn with the Plug'n play nodeLinker.
In conclusion : after several days looking for good practices, examples I'm a bit lost since the problem presents different dimensions :
How to build each APIs and bundle it with its local dependencies (common libraries) ? The deployment is done using a docker image so we can install the external dependencies from the package.json at the image construction phase.
Do we really need webpack ?
How to serve the static resources of swagger ?
I followed the NestJS monorepo documentation but it doesn't correspond our problem since the company's monorepo contains severals APIs and their libraries but also a web application and a react-native application targeting Android. Both of those projects which are not nest projects are also using the shared libraries.
I'm ready to refactor the whole monorepo configuration but I need a good sample/example to base my work on.
Thank you for your help, pointers or any idea
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 1 year ago.
Improve this question
I have the following project structure:
/app
/components
/TextInputs
SearchInput.js
TextInput.js
/Buttons
Button.js
CircleButton.js
/screens
...
/utils
...
/services
...
/theme
theme.js
I have seen people using index.js files for importing/exporting stuff, in order to clean all imports of the app.
Is this the main purpose of index.js? Is it a good practice to have a index.js per directory?
If you need to import multiple files from a folder like:
import {SearchInput} from './components/TextInputs/SearchInput'
import {TextInput} from './components/TextInputs/TextInput'
I would recommend creating an index file. This reduces the amount of import statements you are going to use in other components:
/app
/components
/TextInputs
SearchInput.js
TextInput.js
index.js
with the content: (/TextInputs/index.js)
import {SearchInput} from './SearchInput'
import {TextInput} from './TextInput'
export {SearchInput, TextInput}
and use it on the other components like:
import {TextInput, SearchInput} from './components/TextInputs'
This is why the index.js is used mostly, and makes the imports more managable and readable for some cases. Entirely up to developer!
It's likely more personal preference than not, but I think indexes has 2 main benefits.
It lets your user know that this file is the key and main file for that directory, like if I see an index.scss in /style I immediately assume that index will #import other partials. If I see an index.js in a root dir I immediately assume it's probably what package.json is referring to. So in a sense it's communicating things to you.
Most typescript/react project will allow importing with index without having to specify the index file and it will automatically load it for you.
// ./src/example/index.js
import Example from './src/example'
...
// ./theme/index.scss
import './theme'
Which will automatically import the index.
This also helps a lot when you're using something like css modules or styles per component where it's stored in the same directory, so that you can still import the normal component without having to do something like import Header from './Header/header.js'.
There is a caveat though, while it serves some benefits it can also be difficult to debug sometimes when you have 20 files called index, when one of them breaks and the debugger is only telling you it's in a file called "index.js" without being more specific about which file or what directory.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
TFLite node module gives error when it is required in Node.js, it gives "Blob is not defined" error.
https://www.npmjs.com/package/#tensorflow/tfjs-tflite
index.js file
require("#tensorflow/tfjs-tflite");
package.json file
{
"name": "tfjs tflite test",
"version": "1",
"description": "",
"main": "index.js",
"scripts": {
},
"license": "UNLICENSED",
"dependencies": {
"#tensorflow/tfjs-tflite": "0.0.1-alpha.4",
}
}
You can see the error log here:
https://i.stack.imgur.com/PInqK.png
TFLite is meant for the web - from tflite's documentation: "This package enables users to run arbitary TFLite models on the web". But apparently, you are running it outside of a web environment - in Node.
TFLite contains a statement which resolves stringified JS by using Blob, as you can see in tf-tflite.node.js:1261. Blob is not known to Node, and that's why you get the ReferenceError once the module resolution kicks in.
You have several options to get around it in your tests:
If you really want to use TF primarily in Node, you are using the wrong package. TF's documentation suggests tfjs-node instead.
If you want to run TF primarily in browsers (web) make sure that you run your Mocha tests in a browser
or include a Blob polyfill for Node in your test suite
or since you are using CommonJS module resolution, you could avoid TFLite from being run by using spies/mocks and replace the dependency by using rewire
I'm trying to inject into the Webpack project, and am faced with the following situation. I have two entry points: about and feedback.
about imports feedback, while both about and feedback are connected to the page. As a result, the code from feedback is duplicated twice.
Question: How can I import feedback into about without including code? That is, to make Webpack import a module from another file.
I know about optimization.splitChunks. In my situation it does not fit. The fact is that I may have many components that are connected on different pages (Maybe several at once). Combining them into one chunk and connecting everywhere is not desirable.
You need to add an additional option called optimization in your webpack config file
module.exports = {
...
optimization: {
mergeDuplicateChunks: false,
}
...
}
Please find the documentation regarding the same here - https://webpack.js.org/configuration/optimization/#optimizationmergeduplicatechunks