how can I "block" imports of a javascript file?
ex: if the file is:
const file = require('./file');
or
import file from './file';
would it be possible to make sure that if there were any of these two forms of import, the file would give an error or would it just not work?
ps: i still want to be able to export
You could have a custom made hook where you could have access to all of the file content and upon that to decide to strip or to load the file but the logic could be quite tangled and complicated if you want to create and common approach. You could read more about custom hooks and decide for yourself if this approach is suitable for you.
Related
Sorry if I'm doing something wrong, I'm just starting with Svelte. I looked around on the web and couldn't find anything
I have a large hard coded data array made of objects that I want to keep in its own file while being able to access the data in app.svelte. I'm trying to keep my app.svelte as simple as possible. I tried export const data=[{data:"mydata"}] along with import {data} from "./data.svelte" but the export keyword means it expects the data to be sent over to data.svelte file, not the other way around. I really have no clue how to acheive this in Svelte. The data could also be json in a json file, as long as it is imported in my app.
Thank you for your help
.svelte files should be reserverd for components only, you can add your data in a regular javascript file instead
in data.js
export const data=[{data:"mydata"}]
in App.svelte
<script>
import { data } from './data.js'
</script>
This is possible with json files as well, but it will require an extra step as svelte does not by default understand json files. Depending on what bundler you use, you will have to add plugin, for Rollup this is https://www.npmjs.com/package/#rollup/plugin-json
I had a problem while making some demo files using TypeScript, each file is considered to run alone (no import or export needed).
The problem is that the files leaked to each other as they all went global (I'll appreciate if someone explains why this happened). I found a few ways to get rid of this as wrapping them in a module or a namespace, or even exporting an empty object.
What I need to know is the best practice that should be done in this situation? which solutions is considered the best? especially that I thought I can face the same situation if I have multiple files that are required for their side-effects only or something.
I had a problem while making some demo files using TypeScript
What I need to know is the best practice that should be done in this situation? which solutions is considered the best? especially that I thought I can face the same situation if I have multiple files that are required for their side-effects only or something.
The only time I've experienced it in my long career as well is with demo files. I had this when creating TypeScript deep dive so I would put in some junk at the top of the file e.g. see const
export var asdfasdfasfadf = 123;
Why its not a concern
You do not see it happening in real world code because you start you brain with module mind set. E.g.
In a file with zero dependencies you are normally thinking : What am I going to export
In a file where you are going to action something you are normally thinking: What will I need to import. As simple as import fs from 'fs' makes it a module 🌹
I hope to explain this in a non-abstract way. I have a problem and I believe that I am pushing the boundaries of Node because there doesn't seem to be much documentation on this particular subject.
To start out, this is my file layout.
//main.js
var 1 = require('1.js');
var 2 = require('2.js');
The purpose of this first file is to load two child files into the process.
//1.js
console.log('Test');
module.exports = function msgUSR(text){
console.log(text);
}
The purpose of this file is to create an export, this export could very obviously be imported into Main.js , however, I have a situation where I need to import a function from 1.js into 2.js without reloading the entire file into memory.
for example.
//2.js
var msgUSR = require('1.js');
msgUSR('blah');
The problem with this setup is that when you require 1.js, it reloads the entire file, including any code that isn't an export.
How could I only import the exports of a file without loading the unrelated code.
Thank you! I know someone has a solution to this.
EDIT:
I understand that the code here wouldn't replicate any useful data. My point is, how do I require a function in another JS file that is already required by a parent file. Instead of writing two long hefty functions that are exactly alike in two different files, I need to be able to call the function from a sister file.
Here is why this is an issue.
If you were to require the file after the parent has required it, 'Test' would appear two times, symbolically meaning that other complex code would also be loaded.
My hopeful result from this question would be a result where I could require the file in such a way as to only import a function from it.
Thanks again.
The problem with this setup is that when you require 1.js, it reloads
the entire file, including any code that isn't an export.
When you require something the file will be loaded once and then is cached
How could I only import the exports of a file without loading the
unrelated code?
You would never have to reload the file once it is already required since Node will use the cached version.
The require function normally has 5 steps:
Resolving: To find the path of the file
Loading: To determine the type of the file content
Wrapping: To give the file its private scope. This is what makes both the require and module objects local to every file we require.
Evaluating: This is what the VM eventually does with the loaded code.
Caching: So that when we require this file again, we don’t go over all the steps another time.
I would like to use javascript classes with one class per file. It is part of a larger project using eslint. I started with:
/*global CSReport*/
/*global CSManager*/
class CSMain {
constructor() {
this.report = new CSReport();
this.manager = new CSManager(this.report);
}
launchReport(...
}
However, eslint generates an error saying CSMain is defined but never used. This led to the idea of using export and import which seemed better than making everything global (side note: CS in front of main is the old style method to avoid global conflicts)
The question is how to put this together. The release version will be a single (uglified) file, so the class file names will no longer exist when they are all concatenated together in (say) csCompiled.js.
Questions:
Import uses a file name. Should I use the CSCompiled.js name rather than the file names before concatenation?
Do I want a single module or a module for each class?
Do I need to export every class and import every class it uses?
I am not fully sure how angular accesses this code but am thinking to import csMain.
I tried to find an answer to this but am only finding older posts that don't use ecmascript 6 and classes. If an answer to this exists, I am not sure how to get to it.
Background:
The main project uses angular 1. This code is separate for legacy reasons. It is currently written in java using gwt, but we want to move to javascript to remove the reliance on gwt. It is about 30-40 files (classes) total to convert.
The code gets and handles data from the server for report requests. There is a lot of pre-processing done before it is handed back to the rest of the UI.
I have used javascript for an established project using angular, but lack expertise on how to create new projects.
I am trying to use basic javascript for this, so it won't need updating if (for example) we go from angular 1 to the current versions. I do not yet know if this is a good way to do it.
ESLint is complaining because you are not exporting the class you created, therefore, it can't be accessed by other modules. You can fix that with a simple line at the end
export default CSMain;
Import uses a file name. Should I use the CSCompiled.js name rather
than the file names before concatenation?
Use the file name before you compile/transpile/uglify/etc. After that it will all become 1 file and the bundler will take care of that for you.
Do I want a single module or a module for each class?
Completely optional, I like to have 1 class per file and then 1 file for the module (index.js) that lists all classes in that module.
Do I need to export every class and import every class it uses?
Yes, you need to import everything your module will use and export everything that should be public or "importable" for other modules.
I am not fully sure how angular accesses this code but am thinking to import csMain.
It all depends on how you export your file. Make sure to import the same name your module/file is exporting.
Does using the JavaScript import statement for images, css and others defeat the purpose of import statement which was designed to import only the JS Modules ?
Of course, for now it gets transpiled to ES5 require using webpack. But that same question comes up again. Is it incorrect to use import statement to import images or css or files ?
EDIT:
I like the idea of controlling imports that we can control the assets on build time in such a clean way - The idea that I use the image path to import the image, and
on different environments the image path would contain different values - url or path
this image can be compressed on build time
the JS module importing this image can contain the image dimensions through a custom loader
assets dependency tree is maintained at one place and un-imported items gets chucked away automatically
rebuild time is fast - DX(developer experience) would be good
I guess, this is much better than using any templating, using placeholders in the JS files to inject URLs or paths based on environment during pre-build (webpack).
But using the import statement feels not right to do so in terms of principle or semantics.
This is from Mozilla Developer Network:
The import statement is used to import functions that have been exported from an external module, another script, etc.
From everything I've read on MDN and other sources its purpose is to make a module/script methods and properties available within the current scope it's being imported into.