I'm creating a utility project that will supply React components and resources to my other projects.
I'd like it to include a set of images (mostly .png files for icons) that can then be imported by the child projects.
I can't figure out how to make this work.
I can export the images from the library, and I can see them, name-mangled, in the node_modules of the child project. So, all good so far.
But, import {imgName} from "myLib" does not include the file in the child project's bundle.
It looks to me like my problem is explained by a clue in https://create-react-app.dev/docs/adding-images-fonts-and-files/:
You can import a file right in a JavaScript module. This tells
webpack to include that file in the bundle.
Presumably, CRA is not triggering this webpack behavior in my case, since I'm importing from another module, not from a file.
How can I get things working?
Assume:
I have complete ownership of the library and child projects, so I can change this solution in whatever way works. I just want to have a single common resource for the images.
I don't want to eject my child projects
Ideally, any complexity should be in the library project. The child projects should have minimal complex tooling. (My intent is for this library to be used by a team of other developers, who will want to focus on their own tasks; not on tooling details)
EDIT (ADDED LATER)
Per the comments in the first answer below, I've created a simple example of my problem. See:
Library repo: github.com/deg/media-file-bug-library
Library package: npmjs.com/package/media-file-bug-library
Client repo: github.com/deg/media-file-bug-client
Just pull the client repo and do yarn install and yarn start. This will bring up a little web page that shows the problem:
SCREEN SNAPSHOT:
The Problem is Not in CRA Trigger. Importing Png File like JavaScript Hides a Magic. Here you are importing a Image and Exporting it which then get Processed by bundler and The Bundled Index Actually Exports The name of the Processed Image File Which in Your Case is corss~nAalnlvj.png. That's Why Your Image is Broken but you are able to render name of File, The Case is Same for microbundle or parcel.
How You Can solve it is by separating your assets and components By Placing Images on separate assets folder and place your images there and then add assets to files in your files in package.json
{
.
.
"files": [ "dist", "assets"],
}
And Then Import Image & Using Like This
import React from 'react'
import ico_cross from 'media-file-bug-library-fix/assets/cross.png'
function App() {
return (
<div className="App">
<img src={ico_cross} alt="im"/>
</div>
);
}
For Further Reference Checkout
Here
A Npm Library For Your Fix I Published Npm media-file-bug-library-fix
enter image description here
hey David I found the solution please do check the above screenshot
as in you package just change in index.modern.js
// WebPack doesnt listen as a path it listen
// var cross = "cross~nAalnlvj.png";
// use import rather than simple name as it generate a full absolute path at parent level so that in child level it can be accessible as an Image
import cross from "./cross~nAalnlvj.png"
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.
My task is to introduce library to existing create react app based application.
This library need to be build to separate chunk and should not contain any contenthash in name. Ideally should be build to buildDir/js/widget.js and that is.
Currently all my ts are compiled to js during build and are served with contenthash in name.
I don't know how to build widget.js from src/widget/index.ts because entry point is src/index.ts and it never catch src/widget/index.ts because it is not imported anywhere in main entry point.
This widget.js later will be imported in thirdparty web apps via <script> tag and it will be used to initialize some library like MyLibrary.init(...) so I think webpack should also have some info so this one widget.js should export its methods in special way to the browser during importing external script.
What is best way to get this build proces to work. Also it could be really nice to have it also during development with hot updates.
I don't want contenthash in resulting buildDir/js/widget.js because I don't want to ask my customers every time I have new version to update their <script src="..."> for new file name.
Should I eject this CRA? I'm not sure even if I add another entry point that I will be able to control output file name for one entry point as it is and for another without contenthash.
Or maybe it will be better to create separate webpack config (next to unejected CRA) for this widget but then how to run everything in development mode with hot updates?
I'm using webpack 4.42.0 here in this project.
for your case maybe you need this:
https://dev.to/zhiyueyi/include-your-react-widgets-in-any-web-page-emj
https://github.com/ZhiyueYi/demo-react-web-widget
SHORT: Renaming a service or component is no problem, but can you also move it to another folder?
LONG: This is the service I generated at the wrong directory with the ng new service data command:
When I move it from the src folder into the _service folder I'm getting asked, if I want to update the imports. Of course I press yes, but when starting the app I get this error:
Module build failed (from ./node_modules/#ngtools/webpack/src/index.js):
Error: ENOENT: no such file or directory ...\data.service.ts
So I checked the index.js file, if I could update the path to data.service.ts manually, but that's not possible as this is all that is in the index.js file:
"use strict";
function __export(m) {
for (var p in m) if (!exports.hasOwnProperty(p)) exports[p] = m[p];
}
Object.defineProperty(exports, "__esModule", { value: true });
__export(require("./angular_compiler_plugin"));
__export(require("./interfaces"));
var loader_1 = require("./loader");
exports.default = loader_1.ngcLoader;
exports.NgToolsLoader = __filename;
TL;DR: Auto updating imports doesn't seem to work for nested Angular component folders and the error is useless. Check that those imports were updated correctly (anything in the _components folder in the poster's example).
I just ran into this same issue. I'm using the "Move TS" VSCode Extension, and it doesn't appear to update imports in components that are grouped by folders. For example, consider the following folder structure:
> Component 1
> Component 2
> Forms
> Name Component
> Email Component
> Services
api.service.ts
When I moved api.service.ts from its current location into the Services folder, the extension updated the imports in Component 1 and Component 2 correctly. However, it failed to update the imports in the Name Component and the Email Component correctly. I would guess the native VS Code "Update Imports" option has the same defect. So I would check your _components folder to ensure the imports were updated correctly.
We can move the services and components to desired folder. In Visual Studio Code after moving the component or service you would have to manually remove the initial imports and add than do Auto import from Source Action then it would update the dependencies correctly
Visual Studio Code does not seems to auto update the imports in this case.
The only way I think is to move the files in to desired location using any code editor(used vscode) and manually update the imports. VS code also takes care of GIT. If we do it from the folder structure I think we need to delete and add the file.
In VS code, you can simply rename the component to include the folder you want to use as a container and everything will be updated automatically.
Let's say you have some like:
And you want to move the component named 'single-value-card' to the 'visualization' folder.
Then all you have to do is to rename the component folder as shown:
And voilá:
Note: After renaming, VS Code will ask you if you want to apply the reference refactor. As I've answered 'Always apply the reference update' (or smth like that) it never asked me again
I have been pulling my hair out for 3 weeks trying to get this to work, and I can't figure out where the gap in my understanding is.
I am building a library of components for an authorable CMS. My vision is to have a set of n thin entrypoints, all of which will have statically imported dependencies that are requested when the entrypoint is run via script tag.
Per my understanding, webpack can chunk shared dependencies together via splitChunks plugin, and those dependencies can be automatically loaded via the bundle-loader plugin.
However, when I call an entrypoint bundle via script tag, the automatic dependency import does not occur - only when I use dynamic import() syntax within my source files does dynamic import occur - but that's because import() itself is dynamic.
How can I configure webpack to pull in statically dependent chunks?
Check out Paragons (see section: Code Splitting). Then take a look at CodeSplitPage which is wrapped in a Loadable using a dynamic import.
The HtmlWebpackPlugin is what you're looking for. You can configure it to generate entry.html output files in your dist folder, which you can then use in an Express application, or import into your non-Node server rendering to get the full list of <script> tag.
When I work with angular2 code I often need to see the implementation of a class, let's say the Router class.
If I click on the Router type in my IDE WebStorm, e. g. inside the constructor of another class
export class myClass {
constructor(private router: Router) {}
// ...
}
my IDE takes me to the TypeScript definition file router.d.ts inside my node_modules folder. What I want is it to take me to the original router.ts file with the implementation of the router class, not just its definition.
The original .ts file is not included in the node_modules folder structure when you get angular2 from github via the standard package.json suggested in the Angular2 Quickstart. Currently, I have to look up the original code in the official github repo.
Any ideas how to get the .ts files into my node_modules/#angular folder instead of the .d.ts files?
Sadly, it's not possible since no TS files exist. Even if you add them it still not possible since you import real angular paths which always point to the definition files. On top of that the file structure of the project does not correlate to the structure of the import string literals.
Some background and more information
The NPM package does not include .ts files, this is by design from the angular team. Up until some time ago the .ts files were indeed supplied with the NPM package.
The reasoning for removing them is to disable abuse from users accessing private classes and #internal and private APIs which is public methods/properties in the API that are not supposed to be public but must be so other angular internal classes can use them.
We used to see a lot of code samples out there doing things like import { PromiseCompleter } from 'angular2/src/facade/lang'; (before RC0) but this was changed when the project structure had a big structure refactor in RC0. This abuse was wide and it's bad, very bad... For users and for Angular PR.
The Angular project has a complex and robust build process where all of the API is moved from .ts files into d.ts files using an automated process that limits exposure. (public_api_guard)
The end result is d.ts files only.
It's also not possible to clone the git repo and use it since, again, the file structure is way way different so imports will have to change. Most importantly without the build Angular will, most likely, not work.
A solution using a different approach
However, if you debug your app you notice that you reach actual angular core .ts files in the source view of the console, this is because the NPM package comes with source map files that include the whole TS source code. Nice trick they did there.
This is what I use to dig deep into angular, it works quite great and I get a lot from it.
It's not as nice as Goto Declaration but it something...
IMO it's also easier to understand when you step through code...