Should I be importing my node modules using *
example
import * from 'express';
import * from './../../myCode';
Is it correct that by using the * that all exports will be imported which will make me bring functionality which will increase the file size.
import * as myCode from './../../myCode';
This inserts myCode into the current scope, containing all the exports from the module in the file located in ./../../myCode.
import React, { Component } from 'react';
class myComponent extends Component { ... }
By Using above syntax your bundler ( e.g : webpack) will still bundle the ENTIRE dependency but since the Component module is imported in such a way using { } into the namespace, we can just reference it with Componentinstead of React.Component.
For more information you can read mozilla ES6 module docs.
The answer is, it depends: there is no best practice for import/export since it's very up to you and your use-case. But normally I will just import what I need, not everything. And yes, if you do import * the file size of bundle.js can be big.
Related
Module: shared-module
export * from "./common-types";
export * from "./lots-of-large-classes"
Let's say I have 200 large classes and import the above module like
Module: Main
import { CommonTypeClass } from "shared-module"
Now all 200 classes "also" will load as they are resolved in static scope and referred in my import.
To avoid this I tried
Object.defineProperty(module.exports, 'lots-of-large-classes', {
// The lots-of-large-classes folder is very large. To avoid pulling it in from static
// scope, we lazy-load the module.
get: () => require('./lots-of-large-classes'),
});
But VS Code isn't showing the lots-of-large-classes import.
import { LargeClassOne } from 'shared-module/lots-of-large-classes'; // ISN'T WORKING
However, above solution also still loads all classes as there is an index file which loads all classes.
How can I selective load LargeClassOne from lots-of-large-classes folder without loading other classes through shared-module?
Something like with overhead of loading one large class alone which is being imported.
import { LargeClassOne } from 'shared-module/lots-of-large-classes';
It's not possible to statically import dynamically-loaded data. Using subpath exports in the package.json for "shared-module" will help you accomplish your goal.
You can combine this with TypeScript's path mapping feature for very flexible import specifiers.
I want to organize my firebase cloud functions in specific files,
and currently, I have these 3:
index.ts
crypto.ts
webscrape.ts
Inside of these files, I have functions that use specific dependencies that are needed nowhere else.
For example, in crypto.ts I need the crypto-js package to encrypt some user data and store it into the database.
So I am importing it like so:
import * as CryptoJS from "crypto-js";
as advised in https://firebase.google.com/docs/functions/handle-dependencies#typescript
On the other hand, when I try to import puppeteer into webscrape.ts like this:
import * as puppeteer from"puppeteer-extra";
then calling puppeteer.launch(); gives me an error :
Property 'launch' does not exist on type 'typeof import("c:/Users/username/Desktop/project/firebasee/functions/node_modules/puppeteer-extra/dist/index")'
and it only works when I do const puppeteer = require("puppeteer-extra");
What's the difference here?
My goal is to keep the dependencies of each functions and file/module as small as possible because I assume that this will also keep the size of each function container small (Is that even true?)
I didn't want to import everything to index.ts even when I trigger a function, that doesn't use this dependency at all.
So what is the correct way of handling these dependencies?
Thanks!
The following import will get the default export from that package.
import puppeteer from "puppeteer-extra"
I looked for the default export in the Github repository and found that.
const defaultExport: PuppeteerExtra = (() => {
return new PuppeteerExtra(...requireVanillaPuppeteer())
})()
export default defaultExport
They have mentioned both ES6 import and require methods here.
// javascript import
const puppeteer = require('puppeteer-extra')
// typescript/es6 module import
import puppeteer from 'puppeteer-extra'
You can read more about import on MDN.
So my issue is when i do "create-react-app" in terminal it creates everything like it should but in App.js it should be importing React and { Component } from "react" by default no?
Because right now it does this:
import React from "react";
And not this:
import React, { Component } from "react";
And also it's not doing: class App extends Component { ... }But rather: function App() { ... }
So when i try to use state it just fails to compile saying 'state' is undefined because of course it is if it's not importing Component.
Why is that? I have the latest version of Node.js installed. I really don't want to redo imports everytime i run create-react-app.
I'm learning React so maybe i did something wrong with my install or something, i don't know. I'm hoping it's something i overlooked and that it's easy to solve, maybe start fresh?
There are two kinds of components, Class components and Functional components. You can use whatever approach you like, either class components that extend the React.Component or functional components that do not extend the React.Component because they are pure functions. https://reactjs.org/docs/components-and-props.html
I have a small node package that I would like users to only used named imports in their project.
import { Logger } from 'logger';
However, there is nothing stopping the user from doing
import defaultImportedLogger from 'logger';
They will just learn the hard way when they find out that defaultImportedLogger is undefined because my project doesn't have an export default anywhere. Hence the default export is undefined.
If I try to import a named exports such as:
import { foo } from 'logger'
my editor will complain because foo isn't exposed. Why doesn't my editor complain in the default import situation?
The result of trying to import the default export when it wasn't defined depends on which bundler you're using. For example Rollup throws an error: "'default' is not exported by <filename>".
I don't think there's any way to prevent users from importing the default export. The best you can do is export a function which throws an error when called, with error message "Don't use the default export".
I want to develop a node module in TypeScript, but I'm having some problems with all the possible options to require, import, etc.
What I'm doing right now is having every class and interface in it's own file. So I would need to require all the dependencies which is kind of stupid, because I'm typing the class name twice, like this:
import Target = require('./Target');
export interface IFace {
getTarget(): Target.Target
}
I could write import t = require('./Target'); instead but then I need to write t.Target which I think is also pretty ugly.
And also I can't give it a module name (like FaceApp), because when I need to import two files, there's a naming conflict.
Obviously that would not be needed if everything would live in one file, but this is far from optimal I think.
So how do you guys organize your node module in TypeScript? I'd be happy to hear your suggestions.
You can avoid the name duplication by using the export = syntax. i.e. Do:
class Target{}
export = Target;
instead of export class Target.
Also grunt-ts transformers can help you with the import statement explosion : https://github.com/grunt-ts/grunt-ts/issues/85#issue-29515541
The way recommended by TypeScript is to do
export default class Target {}
and then you can do a true typescript import with
import Target from './Target'
alternatively, you can rename it
import NewName from './Target'
Also note that you can export multiple things from a file if they are related
export class SomeClass {}
export class OtherClass {}
And that on import, you can change the names
import { SomeClass as MySomeClass, OtherClass as MyOtherClass } from './Target'