We Keep Coding

How to config moduleNameMapper for monorepo react apps?

I am trying to configure jest for my monorepo react app.
This is my file structure.
├── Dockerfile
├── Procfile
├── README.md
├── VERSIONLOG.md
├── apps
│ ├── admin
│ ├── business
│ └── consumer
├── config
│ ├── env.js
│ ├── getHttpsConfig.js
│ ├── grp-config.js
│ ├── jest
│ ├── modules.js
│ ├── paths.js
│ ├── utils
│ ├── webpack.config.js
│ └── webpackDevServer.config.js
├── core
│ ├── components
│ ├── constants
│ ├── external-scripts
│ ├── services
│ ├── static
│ └── utils
├── docker-compose.yml
├── jest.config.js
├── package-lock.json
├── package.json
├── public
│ ├── favicon.ico
│ ├── index.html
│ ├── logo.png
│ ├── manifest.json
│ └── robots.txt
├── pull_request_template.md
├── scripts
│ ├── build.js
│ ├── build_parametrized
│ ├── lint.js
│ ├── server.js
│ ├── start.js
│ └── test.js
├── shared
│ ├── components
│ ├── constants
│ ├── helpers
│ ├── hooks
│ ├── redux
│ ├── selectors
│ ├── services
│ └── types
├── static.json
├── tests
│ ├── admin
│ ├── business
│ ├── consumer
│ ├── core
│ ├── mocks.ts
│ ├── setupTests.ts
│ ├── shared
│ └── utils.tsx
├── tools
│ └── git-hooks
├── tsconfig.json
└── version.json
Every separate app has its own tsconfig.json which is merged with the one on the root.
For example Admin app has this tsconfig.json.
{
"compilerOptions": {
"baseUrl": "./",
"paths": {
"components/*": [
"src/components/*"
],
"constants/*": [
"src/constants/*"
],
"helpers/*": [
"src/helpers/*"
],
"pages/*": [
"src/pages/*"
],
"reducers/*": [
"src/reducers/*"
],
"selectors/*": [
"src/selectors/*"
],
"types/*": [
"src/types/*"
],
"hooks/*": [
"src/hooks/*"
],
"styles/*": [
"../../core/static/styles/*"
],
"core/*": [
"../../core/*"
],
"shared/*": [
"../../shared/*"
],
}
},
"include": [
"../../shared",
"../../core",
"../../apps/admin"
],
"extends": "../../tsconfig.json"
}
When I am running my tests, jest throws an error
Cannot find module 'pages/root' from 'apps/admin/src/routes.ts'
moduleNameMapper: {
"^core(.*)$": "<rootDir>/core$1",
"^apps(.*)$": "<rootDir>/apps$1",
"^shared(.*)$": "<rootDir>/shared$1",
"^styles(.*)$": "<rootDir>/core/static/styles$1",
"styles.ts": "identity-obj-proxy"
},
I have managed to add shared and core path mappers for jest, but can't do it for the separate apps.
"^apps/admin/src/pages(.*)$": "<rootDir>/apps/admin/src/pages$1",
Have tried this one and others, nothing helped me

kaboom.js failed load image

I can't load image in kaboom.js .this my code files root D:\kaboom\src . this my image file root D:\kaboom\public\assets.
js code
import kaboom from 'kaboom';
kaboom({
font: "sinko",
background: [0, 0, 255,],
})
loadSprite("bean", "assets/ii.png");
// add a character to screen
add([
// list of components
sprite("bean"),
pos(80, 40),
area(),
]);
what I am mistake

Where is your index.html?
I use React to build this game, and set these public files adjoined index.html. Like this:
.
├── MarioGames
│ └── sprites
│ ├── Items.png
│ ├── Mario.json
│ ├── Mario.png
│ ├── OverWorld.json
│ ├── OverWorld.png
│ ├── bigMushy.png
│ ├── brick.png
│ ├── castle.png
│ ├── cloud.png
│ ├── coin.png
│ ├── emptyBox.png
│ ├── enemies.json
│ ├── enemies.png
│ ├── ground.png
│ ├── hill.png
│ ├── pipe.png
│ ├── pipeBottom.png
│ ├── pipeTop.png
│ ├── questionBox.png
│ └── shrubbery.png
├── favicon.ico
├── index.html
├── logo192.png
├── logo512.png
├── manifest.json
└── robots.txt
It's my solution.
kaboom({
background: [134, 135, 247],
width: 320,
height: 240,
scale: 2,
canvas: this.refs.canvas as any,
})
loadRoot('./MarioGames/sprites/')
loadAseprite('mario', 'Mario.png', 'Mario.json')
loadAseprite('enemies', 'enemies.png', 'enemies.json')

Next.js: How to use source-map-explorer with Next.js

I want to analyze my Next.js build with source-map-explorer. Can someone please help me with the script?
With React (CRA), I use the following script:
"build:analyze": "npm run build && source-map-explorer 'build/static/js/*.js'",
npm run build:analyze
Is there a similar way to analyze the build inside the .next as well?
UPDATE
.next/ File Structure:
.next
├── BUILD_ID
├── build-manifest.json
├── cache
│ └── webpack
│ ├── client-production
│ │ ├── 0.pack
│ │ └── index.pack
│ └── server-production
│ ├── 0.pack
│ └── index.pack
├── export-marker.json
├── images-manifest.json
├── prerender-manifest.json
├── react-loadable-manifest.json
├── required-server-files.json
├── routes-manifest.json
├── server
│ ├── chunks
│ │ ├── 129.js
│ │ ├── 398.js
│ │ ├── 50.js
│ │ ├── 649.js
│ │ ├── 664.js
│ │ ├── 690.js
│ │ ├── 803.js
│ │ ├── 825.js
│ │ └── 859.js
│ ├── font-manifest.json
│ ├── pages
│ │ ├── 404.js
│ │ ├── 500.html
│ │ ├── _app.js
│ │ ├── _document.js
│ │ ├── _error.js
│ │ ├── api
│ │ │ └── get-config.js
│ │ ├── auth
│ │ │ ├── login-error.js
│ │ │ ├── login-success.js
│ │ │ └── vendor-repair.js
│ │ ├── help.js
│ │ ├── home.js
│ │ ├── index.js
│ │ ├── onboarding.js
│ │ ├── photo-gallery-details.js
│ │ ├── photo-gallery.js
│ │ ├── popup.js
│ │ ├── practise.js
│ │ ├── privacy-policy.js
│ │ ├── profile.js
│ │ ├── reference-documents.js
│ │ ├── repair-details.js
│ │ ├── repair-request.js
│ │ ├── stage-area.js
│ │ ├── store-comments.js
│ │ ├── store-visit-checklist.js
│ │ ├── store-visit-history.js
│ │ ├── visual-merchandise-details.js
│ │ └── visual-merchandise.js
│ ├── pages-manifest.json
│ └── webpack-runtime.js
└── static
├── chunks
│ ├── 29107295-62449f6ab50432c0efef.js
│ ├── 475-f51e5d80bd683f3b5684.js
│ ├── 4a3ea9cd-27e375e040b0a04d492d.js
│ ├── 514-2f11410f8595f17ec257.js
│ ├── framework-c179ed8d0295df0a6019.js
│ ├── main-c9abfc3dcd7802a764ed.js
│ ├── pages
│ │ ├── 404-8481e9d7d36e8670eb39.js
│ │ ├── _app-eb5037c043313bbfb3fc.js
│ │ ├── _error-a33892d286e78bfa334d.js
│ │ ├── auth
│ │ │ ├── login-error-8141cf890a77a08b5fd7.js
│ │ │ ├── login-success-494df6631cb3f5141e9a.js
│ │ │ └── vendor-repair-bed782e18fed509b3903.js
│ │ ├── help-e318e021fc815ad4c48a.js
│ │ ├── home-c6c8b871ab5c5738665e.js
│ │ ├── index-bd34bcc4cc28f9419b8d.js
│ │ ├── onboarding-07120812010a84501867.js
│ │ ├── photo-gallery-details-f515c1b20e11f414190b.js
│ │ ├── photo-gallery-e3972e175274149dba6b.js
│ │ ├── popup-81f14fa216f8b1def307.js
│ │ ├── practise-2b8d378b633a9b426aab.js
│ │ ├── privacy-policy-5c65687e77deed0661a0.js
│ │ ├── profile-58058efb871cd14f8a2e.js
│ │ ├── reference-documents-6507fb50d903d9b6881e.js
│ │ ├── repair-details-e2e94513e20e98f7e274.js
│ │ ├── repair-request-26a0d3902ac752eafeab.js
│ │ ├── stage-area-64d34fda6a621eecdc1c.js
│ │ ├── store-comments-9dbd60b5353c708b220b.js
│ │ ├── store-visit-checklist-411682c351d799fe983a.js
│ │ ├── store-visit-history-224243943fdb8ae73663.js
│ │ ├── visual-merchandise-88be768dfe1fc5ada55f.js
│ │ └── visual-merchandise-details-c102d8d548e4757a72e6.js
│ ├── polyfills-7b08e4c67f4f1b892f4b.js
│ └── webpack-e5108aeecfc3e7f070df.js
├── css
│ ├── 03632b0eee83f601f359.css
│ └── f999bd706539c2e100c7.css
├── media
│ ├── Metropolis-Medium.251ab6a3f9cf79779269596ecbe28574.eot
│ ├── Metropolis-Medium.a8208f13e1711b160eabc04bafbd04d9.ttf
│ ├── Metropolis-Medium.bff42e1c5682f2689bdc8e47a3753b27.woff2
│ ├── Metropolis-Medium.f23d75633ae80143c0f4d819d6a0d323.woff
│ ├── Metropolis-Regular.360d0f5a8067816addd5a4da45aaa660.eot
│ ├── Metropolis-Regular.b54f45f08c62b81d0078de96bb920cd9.ttf
│ ├── Metropolis-Regular.cd75f7c84a6375cdee1928c936c13a20.woff
│ ├── Metropolis-Regular.e90dcb53335abcd72603e0718c6c8cd2.woff2
│ ├── Metropolis-SemiBold.03a3e314fb58e1b6fe4104e24dee09a7.woff
│ ├── Metropolis-SemiBold.1c6f27c0abbd4b2a94f84e21efc14265.eot
│ ├── Metropolis-SemiBold.3af64c0941a01fed6ea3e61028323897.woff2
│ ├── Metropolis-SemiBold.bdaa1ae71421dd75bb29537a78b2ed08.ttf
│ ├── ajax-loader.fb6f3c230cb846e25247dfaa1da94d8f.gif
│ ├── helveticaneue-bold.54da3e9e715c351fef284c8fe3d191d2.eot
│ ├── helveticaneue-bold.80c2aa2e5c685eae489425fd673346f0.woff
│ ├── helveticaneue-bold.b17142a9ee042ff5cfecce7bc12f3513.ttf
│ ├── helveticaneue-bold.b82ee7f1ae8568f0d6bae2b98b4bff46.svg
│ ├── helveticaneue-bold.f66775fae72ac8325a23028c5accda16.woff2
│ ├── helveticaneue-light.61226a60a0b5787be0fba7d142ee703d.woff2
│ ├── helveticaneue-light.6e3ec2feb1535ebf53e9f4d25dcfa94f.woff
│ ├── helveticaneue-light.d846f89ab1d295bd315d9c71167df502.svg
│ ├── helveticaneue-light.ddf262cb96782fefcbc8984c8131a471.eot
│ ├── helveticaneue-light.fb11a81f919945d13c73b549d4e7e1e1.ttf
│ ├── helveticaneue-medium.29744a2c2edcc640ecb99d2de05f9c2e.woff
│ ├── helveticaneue-medium.4a368f8dd72410bb7e6ffe37e91100c4.ttf
│ ├── helveticaneue-medium.54e305719b6cfc7db698fa584ea9e738.woff2
│ ├── helveticaneue-medium.8aca99ab7abac084902d2fcd8a68625e.svg
│ ├── helveticaneue-medium.bfaaa603f19e12a88d35305f96b4b25f.eot
│ ├── slick.2630a3e3eab21c607e21576571b95b9d.svg
│ ├── slick.295183786cd8a138986521d9f388a286.woff
│ ├── slick.a4e97f5a2a64f0ab132323fbeb33ae29.eot
│ └── slick.c94f7671dcc99dce43e22a89f486f7c2.ttf
└── pNP1560UJNYEPcr4n-2-U
├── _buildManifest.js
└── _ssgManifest.js

I recently configured the next.js with source-map-explorer.
Follow these steps:
Install source-map-explorer:
npm install -D source-map-explorer
Update the next.config.js file:
module.exports = {
productionBrowserSourceMaps: true
// ...Other configs if any.
}
Note: This makes the build process slower.
Add scripts:
"scripts": {
"analyze": "source-map-explorer .next/static/**/*.js",
"build": "next build",
"build:analyze": "npm run build && npm run analyze"
}
PS: You might need to delete the .next folder and then run the command if source maps are generated.

You'll need to enable source map generation for the production build in your next.config.js file as it's disabled by default.
// next.config.js
module.exports = {
productionBrowserSourceMaps: true
}
You can then modify your npm script to target the right folder within the .next directory.
"build:analyze": "npm run build && source-map-explorer .next/static/**/*.js"

Setup Shared folder in a MERN repository

I am working on an application using the MERN stack. The backend and frontend are in the same repository with this hierarchy:
my-project/
├── backend/
│ │
│ .
│ .
│ └── package.json
├── frontend/
│ │
│ .
│ .
│ └── package.json
├── shared/
│ ├── constants/
│ .
│ .
│ ├── index.js
│ └── package.json
├── package.json
└── README.md
I want to have my constants shared between both the backend and frontend. I have the constants in the shared folder/module.
I also want to have any change in the shared package to be reflected in the other packages without needing to reinstall.
What is the best way for both the backend and frontend to use the shared package as a dependency?

You directory structure is almost ok to work with. But there might be some flaws,
my-project/
├── backend/
│ │
│ .
│ .
│ └── package.json
├── frontend/
│ │
│ .
│ .
│ └── package.json
├── shared/
│ ├── constants/
│ .
│ .
│ ├── index.js
│ └── package.json // You might not need this
├── package.json // define shared packages here
└── README.md
For more details, how node

Optimal directory structure for app -- node + dojo: would this work?

I am trying to work out the best directory structure for a small Dojo application (it's a basic booking system).
I am just about finished writing login/registration.
Here is what I have now:
.
├── app
│ ├── client
│ │ ├── JsonRest.js
│ │ ├── lib
│ │ │ ├── defaultSubmit.js
│ │ │ ├── globals.js
│ │ │ ├── globalWidgets.js
│ │ │ ├── Logger.js
│ │ │ └── stores.js
│ │ ├── login.js
│ │ ├── main.css
│ │ ├── main.js
│ │ ├── register.js
│ │ ├── rrl.css
│ │ ├── TODO.txt
│ │ ├── validators.js
│ │ └── widgets
│ │ ├── _AjaxValidatorMixin.js
│ │ ├── AlertBar.js
│ │ ├── AppMainScreen.js
│ │ ├── BusyButton.js
│ │ ├── css
│ │ │ └── AlertBar.css
│ │ ├── Dashboard.js
│ │ ├── LoginForm.js
│ │ ├── RegisterForm.js
│ │ ├── SearchPage.js
│ │ ├── StackFading.js
│ │ ├── _StackFadingMixin.js
│ │ ├── TabFading.js
│ │ ├── templates
│ │ │ ├── LoginForm.html
│ │ │ ├── RetypePassword.html
│ │ │ └── SearchPage.html
│ │ ├── ValidationEmail.js
│ │ ├── ValidationPassword.js
│ │ ├── ValidationUsername.js
│ │ ├── ValidationWorkspace.js
│ └── server
│ ├── AppErrorHandler.js
│ ├── auth.js
│ ├── db.js
│ ├── globals.js
│ ├── node_modules
│ │ ├── express
│ │ ├── jade
│ │ ├── mongodb
│ │ └── mongoose
│ ├── public
│ │ ├── app -> ../../client/
│ │ └── libs -> ../../../libs
│ ├── routes
│ │ └── routes.js
│ ├── server.js
│ ├── test.js
│ └── views
│ ├── index.jade
│ ├── login.jade
│ └── register.jade
├── libs
├── build-report.txt
├── dojo -> dojo-1.7.1
├── dojo-1.7.1
│ ├── app -> ../../app/client
│ ├── dijit
│ ├── dojox
│ ├── dojo
│ └── util
└── dojo-1.8.0
├── app -> ../../app/client
├── dijit
├── dojox
├── dojo
└── util
The idea behind it is that:
the "app" directory will be in a git repository somewhere (it's about time I make one, actually). It has the directories "client" (all the client-side code) and "server" (the node code).
In "libs" I will add things like dgrid, etc. I also noticed that Dojo 1.8 can be loaded within node (!). I will play with this later -- exciting!
Now, here you can see that I basically used symbolic links to make things work.
SERVER side: Under "public", I had symlinks to "app" and "libs". That way, I can access, from HTML, things like /libs/dojo/dojox/form/resources/BusyButton.css, or (important!) /libs/dojo/dojo/dojo.js and /app/main.js (which then instances AppMainScreen with a simple require(["app/widgets/AppMainScreen" ], function( AppMainScreen){ ...
CLIENT side: I have a symlink to the latest Dojo (my boilerplate still has a problem with Dojo 1.8, so I am still using 1.7 for now). However, in order to make this work within the app:
require(["app/widgets/AppMainScreen" ], function( AppMainScreen){
I have a symlink to "app" within Dojo.
Now: I realise the basics (I think the symlink to "app" within Dojo is solved by simply using DojoConfig, for example). But... well, this is my current 100% unoptimised, never built tree.
I can ask you guys give me the tick of approval for this tree? Will it work once I start "building" things? (I am still miles away from doing it, but I will eventually otherwise my [pregnant] wife will go crazy!). Avoiding that symlink to "app" is one of the things I think I should do (but then again, do I need to?).
Thank you!
Merc.

While not being a fan (nor knowledgable at all) of node, it looks to me as there's a huuge javascript library :)
I'd suggest You should really consider making a buildprofile and use the prefix key to set the location of your scripts. As result of a build, you would automatically get an 'app' folder coexisting with dojo,dijit,dojox.
Actually, i would suggest that once there is a separate repository for your dojo application layer, simply do the checkout within the SDK root, e.g. :
wget download.dojotoolkit.org/dojotoolkit-1.7.2-src.tar.gz -O djsrc.tar.gz && tar xfz djsrc.tar.gz && rm djsrc.tar.gz
cd dojotoolkit-1.7.2-src/
svn checkout http://example/mylibrary app
sh utils/buildscripts/build.sh --profile app/package.profile --release /var/nodejs/docroot/lib/
There is no harm at all in developing your app.widgets somewhere else then in your main document root (/lib). You could simply setup one global variable that tells loader where to look.
If built, nothing should be nescessary, but as far as your current tree goes, try something like this
<script>
var isDevelopement = true;
var dojoConfig = {
packages : (isDevelopement) ? [ name: 'app', location: '/app/client/' ] : []
}
</script>