I want to boost my website performance. I recently see an error on unused javascript from lighthouse.
I checked the bundle and apparently those unused javascript are actually being used from other modules and node packages which I have been download.
For example, #sentry/node is what I'm using, but report shows unused javascript from #sentry/hub. But I only did install on #sentry/node but not the whole #sentry package. Further more, #sentry/node is using #sentry/hub, but I'm not importing #sentry/hub anywhere in my code (which I assume that causes the problem)
I have included "sideEffects": false to my package.json file but nothing seems to work
You could try destructuring, target only the object (or function) you are using.
e.g.
import { Component } from 'react';
Therefore, for you...
import { yourFunction } from `#sentry/node`;
Or simply take the code #sentry/node that you are using. 🤷♂️
Otherwise, show your code:
package.json
webpack.config.js
your "index" file (where you import your scripts and other files)
the file you import #sentry/node in
Related
I'm upgrading a React application and have found that I need to modify the import statements to get them to work.
For example, in the old version, the following import works without errors:
import { User } from '../System'
Note that System is a directory on my file system that contains User, a js file that ends with export default User.
In my upgraded version of the app, the System directory still exists, but the above import gives me Can't resolve '../System' in 'C:\my app\.
It turns out that to get the import working properly now, I need to change it to the following:
import User from '../System/User';
If I understand correctly, this relates to js module system changes made with ES6.
My question, though, is regarding the specification of a directory in the import statement (System above). Why would it be that I was previously able to name a file directory in the import statement instead of the actual js script/module itself? Is that approach of using a directory in the import statement still possible? And if so, is it ever advisable?
Update: based on AKX's comment, I noticed the System directory does indeed contain an index.js, which apparently is what makes the import from the directory itself possible.
When an import points to a directory, and only a file, Webpack (which most React setups use) follows Node's's conventions and will attempt to import index.js from that directory if it exists. That's the only condition under which importing from a path that points to a directory works - your previous build probably had /System/index.js (which would allow importing with from '../System'). If you rename the file you're importing to anything else - such as to User.js - importing using only the directory path will fail.
And if so, is it ever advisable?
Sure, if you want. It's a style choice but is commonly done.
I've a npm package with the following three files in the dist folder (generated by webpack):
Inside the package.json file I've declated the sample.js file as the main one: "main": "dist/sample.js",.
Now I wan't to use this package in another project. Did I need to import all three files? Or should all work fine with one import like import aFunction from 'package-name'?
If there aren't any other weird dependencies, and sample.js is actually the entrypoint of the library (i.e. either you do everything inside it, or you make all the needed exports from it), it should work fine just as you wrote, i.e. import aFunction from 'package-name'.
Btw, is sample.js minified? As far as I remember, starting with Webpack v4 it does the minification automatically for production builds. But you might still want to doublecheck (read here for more info).
I am creating an app with Electron and Vue (using js not ts).
When I run the app using npm run electron:serve the app runs fine.
I now want to build a Windows exe so I can distribute my app. I have tried using electron-builder, electron-packager and electron-forge. Whenever I can get the build to finish, running the exe throws the cannot use import statement outside a module error (referring to the first import statement it finds, i.e. import { app, protocol, BrowserWindow } from 'electron').
I've tried adding "type":"module" to my package.json but (due a bug in Vue, according to this question), that throws Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]
I've also tried changing all my import statements to require but this doesn't work because some of the node modules I'm using use import and the error just throws for those instead.
I'm tearing my hair out over this. Where do I go from here?
UPDATE:
I have found a workaround for the Vue bug and posted my findings on the linked question. I can now add "type":"module" to my package.json.
However, I now get an error thrown when I run npm run electron:serve and from my built exe:
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: <my_project_root>\dist_electron\index.js
require() of ES modules is not supported.
require() of <my_project_root>\dist_electron\index.js from <my_project_root>\node_modules\electron\dist\resources\default_app.asar\main.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
To be clear, I'm not using require in any of my source code, but the compiled(?) version does?
What's going on here?
UPDATE 2:
As requested, here is a minimal reproducible example that maintains original folder structure, configs and package.json
Although I am able to start the npm project using npm start without any issues with webpack or babel, once I run npm test, I find the following error related to testing App.js using App.test.js (where App.js imports ApolloClient):
TypeError: Cannot assign to read only property '__esModule' of object '[object Object]'
| import ApolloClient from 'apollo-boost';
| ^
at node_modules/apollo-boost/lib/bundle.cjs.js:127:74
at Array.forEach (<anonymous>)
at Object.<anonymous> (node_modules/apollo-boost/lib/bundle.cjs.js:127:36)
Essentially, I'm confused as to why I get an error when running the test but not when starting the project.
I've tried adding in a number of babel plugins to both .babelrc and in my webpack config file:
#babel/plugin-transform-object-assign
#babel/plugin-transform-modules-commonjs
babel-plugin-transform-es2015-modules-commonjs
However, I haven't been able to resolve the issue. My thinking was that this is related to the fact that the file that fails to compile was originally CommonJS.
I was only able to find something relatively similar here, https://github.com/ReactTraining/react-router/pull/6758, but I didn't find a solution.
Is there something that I'm missing specifically related to running tests? I should also mention I've tried frameworks other than Jest and ran into the same issue.
EDIT:
I removed everything from App.test.js except the imports to isolate the issue so it just contains the following:
import React from 'react';
import { shallow } from 'enzyme/build';
import App from './App';
UPDATE:
I was able to resolve the initial error by upgrading apollo-boost from version 0.3.1 to 0.4.2. However, I now have a different error that is similarly frustrating. I am using Babel 7 and have added the plugin #babel/plugin-syntax-dynamic-import to both my .babelrc and to my webpack.config.js files. Despite this, I get the following error related to the use of a dynamic import in App.js when running the Jest to test App.test.js:
SyntaxError: Support for the experimental syntax 'dynamicImport' isn't currently enabled
Add #babel/plugin-syntax-dynamic-import (https://git.io/vb4Sv) to the 'plugins' section of your Babel config to enable parsing.
I'm not sure if there is a parsing error or something else, but I've tried numerous things that have not worked. The closest discussion I could find related to this problem is, https://github.com/facebook/jest/issues/5920, however, the proposed solutions don't work for me.
UPDATE:
One thing that I'm trying is to avoid duplication of the babel options as right now they're both in .babelrc and in the babel-loader options within webpack.config.js. From what I found online (Whats the difference when configuring webpack babel-loader vs configuring it within package.json?), the way to make webpack use the settings in .babelrc is to not specify options. However, doing so results in the same error described above showing up only this time when running npm start. I will add that the project that was originally created using create-react-app, however, in order to support multiple pages, I needed to customize webpack's configuration and so ejected from it. I'm not sure why this is so convoluted.
its probably a babel configuration issue, I'm pretty sure jest needs to be compiled to work with create-react-app...
did you specify a setup file in package.json:
"jest": {
"setupFiles": [
"/setupTests.js"
]
}
and in setupTests.js:
import { configure } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';
configure({ adapter: new Adapter() });
It turns out that one of the components in the project's src directory had its own local package.json file even though it wasn't being used and was not installed as a local dependency in the top level package.json (instead imports were done using relative urls). For some reason, the existence of this file changed the behavior of webpack and other tools when starting and testing the project such that none of the top level configurations were used for files within directories with separate package.json files. Once I removed these local package.json files from the components sub-directory, all the prior issues were resolved. One hallmark of this problem is that compilation errors were not showing up for JavaScript files that weren't nested under an alternate package.json file.
Hopefully this is useful for anyone that encounters similar errors as I don't think the cause can be directly determined from the compiler messages alone.
What is the current recommended practice for converting a library written in TypeScript to ES5?
JSPM documentation seems to be geared toward web apps (i.e. with jspm bundle-sfx).
All the articles I can find on Google seems to be assuming a web app workflow rather than a library workflow.
My projects have the following setup:
It depends on react, flux and jquery, all installed through jspm and are properly configured in config.js
The source .tsx/.ts files are located in a src/ tree, along with their corresponding transpiled .js files
I am able to create a bundle with jspm bundle, however, this still requires the end user of my library to be using SystemJS
What I want is to bundle the entire tree under src/ into a single file without libraries such as react or jquery. How can I do this?
So far I've tried jspm bundle src/<MY_MAIN.js> - react - jquery <OUT.js> this works, but user still need a module loader to interact with exported symbols in MY_MAIN.js. I would also like to provide users with an option to manually import my library with <script> tags. self-executed bundles do not seem to work. No symbol is accessible globally once loaded through the <script> tag and I cannot exclude the framework code.
There are basically three approaches that I want to highlight, targeted at different end-user workflows
1. the <script/> tag approach
Here, create an entry .ts file that exports the main symbols of the library like so:
// Main.ts
import {MyLib} from "./components/MyLib";
import * as React from "react";
import * as ReactDOM from "react-dom";
/**
* browser exports
* note, typescript cannot use interfaces as symbols for some reason, probably because they are not emitted in the compiled output
* running `jspm bundle-sfx` results in the code here being accessible in <script /> tag
*/
(function (window) {
window.MyLib = MyLib;
window.React = window.React || React;
window.ReactDOM = window.ReactDOM || ReactDOM;
})(typeof window !== "undefined" ? window : {});
then run jspm bundle-sfx Main.js my-lib.sfx.js, the same works for browserify, except we have to use commonjs style require() instead of ES6 style import
2. Concat & Minify src files through regular gulp/grunt
this should just be the good old workflow we are all familiar with
3. Assume ES6 compatibility for apps that will use the library
Distribute the code as ES6/TS along with .d.ts and assume the user will also use jspm/system or eventual ES6 module loader approach to load your module