My project structure is:
.
├── Adapter
│ ├── Provider
│ ├── Repository
│ └── view
│ ├── build
│ ├── public
│ └── src
├── Application
├── Entity
├── Feature
└── Util
I want to build everything except the view directory, because it will be built by react, but I want to include the react build directory to the tsc build of the whole project.
right now the way I`m doing it is like this:
Project packege.json
"build": "tsc && mkdir build/Adapter/view && cd src/Adapter/view && yarn build"
React package.json
"build": "react-scripts build && mv build ../../../build/Adapter/view",
Project tsconfig.json
"include": ["src/**/*.ts"],
"exclude": ["node_modules", "**/*.d.ts", "src/Adapter/view/src"]
This works fine (except when the build dir already exists, which is annoying), but i really dislike the method, is there a better way of including the build dir?
Related
I have a monorepo setup like:
└── monorepo/
├── package.json
├── apps/
│ └── website/
│ └── package.json
└── packages/
└── elements/
└── package.json
From the monorepo root I'd like to be able to have a command that runs a build watch on the elements package and then concurrently serves up website.
I see that Nx has a run-many command, but that seems more useful if you trying to run a similar command across multiple packages, for example running test on multiple packages at the same time. My situation is different, I want to run build in one and serve in the other.
I'm guessing I'm missing something with the configuration files.
I'm trying to deploy my react app, by serving it using nginx.
The app works perfectly if I serve it using react-scripts start. When I try to serve it with nginx, the main app works fine but the static pages in public folder they don't work.
ex: if I try to navigate to /cgu it redirect me to localhost/cgu.
This is my work directory for (unnecessary files and folders are not mentioned for brevity).
├── Dockerfile
├── docker-compose.yml
├── nginx.conf
├── package-lock.json
├── package.json
├── public
│ ├── assets
│ ├── browserconfig.xml
│ ├── cgu
│ ├── index.html
└── src
├── App.css
├── App.js
├── index.css
└── index.js
This my docker file's content:
FROM node:16-alpine as builder
WORKDIR /app
COPY . .
RUN npm i --legacy-peer-deps
RUN npm run build
FROM nginx:1.21.0-alpine as production
ENV NODE_ENV production
COPY --from=builder /app/build /usr/share/nginx/html
COPY default.conf /etc/nginx/conf.d/default.conf
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
I am currently migrating our monorepo to yarn workspaces. It contains multiple packages and services. Services depends on packages in their respective package.json. I would like to deploy my services to Google App Engine without having to publish the packages to a private npm registry.
I managed to deploy a single service by using a custom runtime and by moving the app.yaml and the Dockerfile to the root of the monorepo in order to have access to the packages and the service in the build context. The issue is that I have multiple services and I cannot have all the dockerfiles at the root of the monorepo, as they have to be named Dockerfile and that I cannot change the build context.
I see 2 naive solutions:
The first would be to move the app.yaml and Dockerfile of the corresponding service to the root of the monorepo before deploying. But this looks quite dirty and would make the CI code very complicated.
The second would be to have a single Dockerfile and service1.yaml, service2.yaml etc. at the root of the monorepo and to pass variables to the Dockerfile. The problem is that I don't see any way in App Engine documentation to pass variables to the Dockerfile of a custom runtime.
My dream solution would be to be able to keep each Dockerfile and app.yaml in the directory of their respective services and to be able to set the build context through the gcloud CLI (like we can do in docker-compose).
Example:
project
├── package.json
├── packages
│ ├── package1
│ │ ├── package.json
│ │ └── src
│ ├── package2
│ │ ├── package.json
│ │ └── src
│ └── package3
│ ├── package.json
│ └── src
├── services
│ ├── service1
│ │ ├── app.yaml
│ │ ├── Dockerfile
│ │ ├── package.json
│ │ └── src
│ └── service2
│ ├── app.yaml
│ ├── Dockerfile
│ ├── package.json
│ └── src
└── yarn.lock
and run something like: gcloud app deploy services/service1/app.yaml --build-context=.
But I don't see any way of doing this in the documentation.
Do you know how I can get closer to my "dream solution"?
Adding possible option suggested in comments to give more visibility.
One possibility would be keeping the docker-compose workflow that you were using and integrate it with your App Engine deploys.
As you were already building your docker images with docker-compose in order to specify the build context, you can push the result of the build operations to Google's Container Registry so the images can be later used to deploy App Engine by using the --image-url flag.
I have created my first react-js app, just saying 'Hello world'. After I change the 'Hello world' to another text, nothing changes when I refresh the browser, even if I empty the cache. The changes take place only when I close the local server and reopen it with npm start. Could anyone help me?
If you want to create new react app from-scratch. You can use :
> npx create-react-app my-app
> cd my-app
> npm start
After that, you will have the initial configured react project structure :
my-app
├── README.md
├── node_modules
├── package.json
├── .gitignore
├── public
│ └── favicon.ico
│ └── index.html
│ └── manifest.json
└── src
└── App.css
└── App.js
└── App.test.js
└── index.css
└── index.js
└── logo.svg
└── registerServiceWorker.js
See react app seed in Github : https://github.com/facebook/create-react-app.
Sam's answer is probably the best way to do it but if you want do refresh it without adding all the bells and whistles of create-react-app you can go for browsersync.
https://browsersync.io/
It watches over your CSS, HTML, JS. I usually use create-react-app but in some cases browsersync does the trick as well.
Following along the getting started example from ZEIT for next.js, I'm getting this error:
error in ./pages/index.js
Module build failed: ReferenceError: [BABEL] /Users/Projects/nextDemo/pages/index.js: Using removed Babel 5 option: /Users/Projects/.babelrc.optional - Put the specific transforms you want in the `plugins` option
What is this error - is it trying to use my globally installed babel? Is there a version mismatch or an update I should be doing?
This is the basic steps I did to get here:
$ npm install next --save
$ mkdir pages
//pages/index.js:
import React from 'react'
export default () => <div>Hello world!</div>
Add a script to the package.json like this:
{
"scripts": {
"dev": "next"
}
}
$ npm run dev
and the installed packages:
└─┬ next#1.2.3
├── ansi-html#0.0.6
├── babel-core#6.18.2
├── babel-generator#6.19.0
├── babel-loader#6.2.8
├── babel-plugin-module-resolver#2.4.0
├── babel-plugin-react-require#3.0.0
├── babel-plugin-transform-async-to-generator#6.16.0
├── babel-plugin-transform-class-properties#6.19.0
├── babel-plugin-transform-object-rest-spread#6.19.0
├── babel-plugin-transform-runtime#6.15.0
├── babel-preset-es2015#6.18.0
├── babel-preset-react#6.16.0
├── babel-runtime#6.18.0
├── cross-spawn#5.0.1
├── del#2.2.2
├── domready#1.0.8
├── friendly-errors-webpack-plugin#1.1.1
├── glamor#2.20.8
├── glob-promise#2.0.0
├── htmlescape#1.1.1
├── is-windows-bash#1.0.2
├── json-loader#0.5.4
├── loader-utils#0.2.16
├── minimist#1.2.0
├── mkdirp-then#1.2.0
├── mz#2.6.0
├── path-match#1.2.4
├── react#15.4.1
├── react-dom#15.4.1
├── react-hot-loader#3.0.0-beta.6
├── read-pkg-up#2.0.0
├── send#0.14.1
├── source-map-support#0.4.6
├── strip-ansi#3.0.1
├── url#0.11.0
├── webpack#1.13.3
├── webpack-dev-middleware#1.8.4
├── webpack-hot-middleware#2.13.2
└── write-file-webpack-plugin#3.4.2
It uses your .babelrc file from the parent directory because:
Babel will look for a .babelrc in the current directory of the file being transpiled. If one does not exist, it will travel up the directory tree until it finds either a .babelrc, or a package.json with a "babel": {} hash within.
Use "babelrc": false to stop lookup behavior.