I'm using wasm pack to build a web app from rust. I went through docs for getting started and was able to build the application with npm init wasm-app dirname and run it in the browser. However, when I change and build the rust code the changes aren't reflected in the app being served. Is there a standard way to re-build (maybe even automate re-building) the rust app and the app built by npm init wasm-app command?
I ended up missing a step. I needed to add
{
app_name: "file:../pkg",
...
}
to the dependencies in package.json
now wasm-pack build updates the app as expected
Related
trying to use servicestack https://github.com/NetCoreTemplates/angular-lite-spa and when execute: npm run dev
got this error. Is there any way to get more informative exeption?
Uncaught Error: Expected 'styles' to be an array of strings.
at assertArrayOfStrings (compiler.es5.js:3796)
at CompileMetadataResolver.getNonNormalizedDirectiveMetadata (compiler.es5.js:15185)
at CompileMetadataResolver._getEntryComponentMetadata (compiler.es5.js:15903)
at compiler.es5.js:15485
at Array.map (<anonymous>)
at CompileMetadataResolver.getNgModuleMetadata (compiler.es5.js:15485)
at JitCompiler._loadModules (compiler.es5.js:26826)
at JitCompiler._compileModuleAndComponents (compiler.es5.js:26799)
at JitCompiler.compileModuleAsync (compiler.es5.js:26728)
at PlatformRef_._bootstrapModuleWithZone (core.es5.js:4536)
Please review ServiceStack's v5 changes for info about ServiceStack's new .NET Core Templates.
The templates are still being refined but I was able to download the angular-lite-spa repo and open the MyApp.sln in VS.NET 2017 which fetches both the server NuGet packages and runs npm install to fetch all the client npm dependencies, after waiting for all npm dependencies to be installed it calls Webpack to generate automatically the wwwrooot\index.html page which is when you can hit F5 to launch the Web App.
For large SPA projects npm can occaisionally have issues with loading some of its many dependencies which you can preview by looking at VS.NET's Output Window (Ctrl+Alt+O) and selecting Bower/npm Output Window from the dropdown. If the index.html was generated correctly and the Web App runs without JavaScript errors it means the project dependencies were successfully installed without issue.
The recommended way to develop with the new templates is with npm run watch (or run the 00-webpack-watch gulp task in VS.NET's Task Runner) which will run a Webpack watch build to re-generate any modified assets on the server. In ServiceStack v5 there's now a built-in hot-loader in DebugMode where it will monitor the server wwwroot folder for any changes and reload the page.
You can still develop with npm run dev but this launches the Webpack Dev Server at http://localhost:3000/ which also requires the backend .NET Core Web App running at http://localhost:5000/.
I've re-tested the latest angular-lite-spa Project on GitHub and all tasks are running without issue including npm run dev which was able to reload the page with TypeScript source file changes.
If you've got JavaScript errors running the default template it's likely due to a corrupted install which you can retry by deleting the node_modules/ folder and running npm install again and monitoring the console window for any issues.
Currently I made a simple app with react, it works perfectly and I use react-scripts. I installed React by following the Facebook github page, and it written that "When you're ready to deploy to production, running npm run build will create an optimized build of your app in the build folder. ". After I press npm run build, a folder build created, but I do not know what to do with this folder. I tried some method like, move all folders except build and npm run, but it did not work. Anyone can explain me what is this folder "build" ? Thank you
npm run build builds the app for production to the build folder.
It correctly bundles React in production mode and optimizes the build for the best performance.
The build is minified and the filenames include the hashes.
npm run build creates a build directory with a production build of your app. Set up your favourite HTTP server so that a visitor to your site is served index.html, and requests to static paths like /static/js/main..js are served with the contents of the /static/js/main..js file.
What are some pro/cons to pushing built code vs. having the server build it?
This is a general question, but here's my specific scenario to illustrate what I'm talking about:
On Heroku I've got a React app that has a simple express server to do OAuth. Currently, I have a postinstall hook in my package.json that runs a webpack production config to do some extract-text stuff and create a dist/ directory with my bundled, uglifyied code. To get all of this to run on Heroku I had to mark pretty much all of my dependencies as 'dependencies' instead of 'devDependencies'.
I know it's a bad practice to check my dist/ into git but it would save me from having to install a dozen plus node_modules on the server. Any thoughts?
I am attempting to set up a xcode project and bot that will build a nodejs application on commit from a github repository and restart the server after the build completes. The bot is currently picking up on the repository changes but fails to build correctly.
I am using a xcode external build tool project that uses /bin/bash as the tool path and the working directory is set to the local repository path.
The bot's after integration script is something like,
npm install --production
npm run build
npm run server:restart
I am getting errors like [npm|node] is not recognized.
Just looking for some clarity to what I might be missing or what could be going wrong.
Add this to the beginning of your script and review the output:
which node
set | grep PATH
This will happen if node is not in your path, which may happen because build scripts have a pretty basic environment - they're not running as a normal user. You may need to add it to your PATH at the start of your build script.
I've developed an Angular website that lives in a Node-based project. Gulp is used to build sources into development and production versions of the site. The project includes an ExpressJS server that can serve either the dev or prod versions of the files. Now I want to build and deploy the site in CI fashion.
I have a private NPM registry that I'm able to publish the entire project module to. The easy route would be:
In the build environment, check out the project repository
npm install
pass tests
npm publish
In the production environment..
npm install project
build for production
Run the server over the newly built prod files
But this doesn't seem right. Shouldn't I output the production files as part of the build process, and publish these as a versioned artifact with NPM? Are there acceptable, different ways to publish an NPM module for development and deployment?
Or am I stuck building my sources in the production environment? Doesn't this defeat the purpose of NODE_ENV=production?
It depends where you are hosting your server.
If you want to deploy to heroku, you can follow https://devcenter.heroku.com/articles/getting-started-with-nodejs#introduction and install the gulp build task https://github.com/appstack/heroku-buildpack-nodejs-gulp. Basically, you will push the version you want to deploy to heroku's git server and it will automatically trigger the build process for dev or prod and start the express server. Assuming you are already using git for your project, it is only a matter of adding a new remote.
If you want to deploy to Amazon's elastic beanstalk, it's a little bit more complicated but it all boils down to pushing your application code to the service and this will trigger the build process in the host instance.
If you want to deploy it on your environment you could still use git push and git hook to trigger the deployment. Check out How can I automatically deploy my app after a git push ( GitHub and node.js)? for various implementations.
As for your question "Shouldn't I output the production files as part of the build process, and publish these as a versioned artifact with NPM": you could, but this is not what most people do. As long as your build process is repeatable, there is no reason to package and publish the built version of your app. I am assuming here that your are building an application and not a reusable library in which case it would be a different story.