I have a project created by vue-cli3. Now I have some files that I use during development, but I don't need them in a production environment.
eg:
I put a file named test.html into /public, and I could access it using http://localhost:8080/test.html (assume project running at http://localhost:8080). When I generate a production version, I don't want this file got included in /dist(default output dir).
All files under /public will be copyed to /dist/static, but it is not the result I expect.
How can I do to get access some files when developing but don't get them involved in production?
Related
I am building a typescript/javascript package that will contain several JSON files. I do not want those JSON files included in the bundle that webpack outputs. I do want those files included in the output folder of the bundled javascript (copied from the node_module directory). This would be similar to including images.
I would like to create directives that explain to webpack what to do vs writing documentation in hopes that somebody reads it and does it correctly.
I know that copy-webpack-plugin will do what I need to do, but not sure how to set up this directive.
Is it even possible?
So
MyPackage has JSON files
Another developer uses my npm-package
Developer uses web pack in their project
Developers webpack bundles the javascript, excludes my JSON files from the bundle, but copies them to the output directory.
Figured it out within the package.json
Create a folder called bin (whatever) on the same level as src.
Copy the contents that need to be included in the package but not compiled or bundled into javascript, such as json files.
Update package.json add the following entry
"files": [
"bin"
],
Now when publishing, the npm package will contain the bin directory. When building within your project using webpack it will recognize this and include those files in the webpack build and deploy as part of the deployment but not in the javascript bundle.
Then from there, your javascript should reference the files similar to reading a file whether it be on the server or client sie.
tl;dr: I want to include some JavaScript files from another project in another directory into a Cordova project, without (manually) copying those files into my Cordova project directory tree. How?
I am editing an existing Cordova project that makes use of some JavaScript source files originally written for a large web application project.
Currently, I am adding these source files by copying them to a subdirectory of the Cordova project, and by adding a <script> tag with the relative path to an index.html file in the Cordova project. This causes the JavaScript files to integrated in the deployed app, apparently by virtue of Cordova's (or Ionic's?) magic.
Now, it would be preferrable for me to avoid copying the JavaScript files to my Cordova project directory. Instead, I would like to directly link to the files in their original location rather than copying them (so updates from the web application get automatically applied to the Cordova project, as well).
As both the Cordova project and the large web application reside in the same VCS repository, the relative path to the files will always be the same - for the sake of an example, like this:
|-repository/
|-web/
| |-src/
| |-myCode.js
|-cordova
|-src
|-index.html
|-helpers
|-myCode.js // copy of /repository/web/src/myCode.js
Therefore, I have tried setting the relative path in the aforementioned index.html file - but unfortunately, Cordova seems to take over that file verbatim, and thus, the resulting URL will not exist (prompting a 404 error in the console, and causing the code from the file to be unavailable).
How can I have Cordova include and reference files from outside the directory hierarchy of a Cordova project?
Is there maybe at least a way to have Ionic or Cordova automatically copy the files into the Cordova project directory upon building the app?
So following this thread In Visual Studio, how can I set the Build Action for an entire folder?
the solution works for me. I have a webpack configuration that creates hashed files in a Build folder that get published. The problem that I have now is that the files that are no longer generated are still available on live.
Here's the scenario:
On every build the script removes everything from the ./Build folder
First time index.js and main.js are generated and are published using wildcard configuration in .csproj file
Second time ./Build folder is again cleaned and only index.js is generated however main.js is still available on live.
I guess it is a problem as beside .js and .css media files are bundled as well, images and fonts are loaded and hashed and in current state it will become quite crowded with a bunch of versions of the same files.
Any idea how to solve this?
Ok so the problem in my case was with the release configuration.
Using TFS as VCS. There I have Visual Studio Build with MSBuild x86 set in advanced configuration. MSBuild configuration has the wildcard to include all files and folders from ./Build folder, which it did.
Now to the problem - for deployments/release I again use a TFS configuration, there I have a task Azure App Service Deploy. This takes the packaged from build configuration and deploy it on server. In the Additional Deployment Options group there's the Remove Additional Files at Destination. Without it files that don't have any matches in the deployed package are not deleted.
Exemple 1 without Remove Additional Files at Destination option:
Deploy location has files: a.js, b.js, c.js
On TFS Build a new package is created with updated a.js, c.js and a new file z.js. Package does no longer contains the file b.js;
The package is deployed
After deploy, deploy location has files: a.js(updated), b.js, c.js(updated), z.js(new)
Exemple 2 with Remove Additional Files at Destination option:
Deploy location has files: a.js, b.js, c.js
On TFS Build a new package is created with updated a.js, c.js and a new file z.js. Package does no longer contains the file b.js;
The package is deployed
After deploy, deploy location has files: a.js(updated), c.js(updated), z.js(new), b.js file is removed from deploy location.
I am trying to push a project I created using the Yeoman's angular generator template to a server.
This is my project -
This is in my app folder -
This is the node-modules folder. For some reason, Yeoman has installed several node-modules. I am not using all of these.
The list goes on. This is just a small snippet of what's in the node-modules folder.
In order to push to the server, I am using grunt build. This generates a dist folder with the following content -
.
However when I navigate to my views, (e.g. reset-password), I get an error that this file is not available.
I am guessing this is because the dist folder doesn't have the views folder that the app folder does.
My final requirement is I want to push this project to the server, so that it is accessible to anyone. I don't want to push all the node-modules because I am not using them.
UPDATE -
This is the content in dist/scripts/ -
In the script.2a4ac124.js file, all my views are referenced but when I try to navigate to - file:///Users/proj/Documents/sso/dist/reset-password I get a file not found error, but when I navigate to file:///Users/proj/Documents/sso/dist/index.html#/ I see the index page.
installing node modules is normal - it installs development dependencies, which will be used in the grunt tasks that Yeoman creates. The reason there are so many is because the dev dependencies have their own dependencies that need to be resolved.
reset-password navigation error is most likely some build error, though it is difficult to tell just from the description. Yeoman converts the view files into angularJS templateCache and puts them into the concat/uglified js file (usually the app-.js file). First see if they are there. If they aren't, the view files aren't getting build. If they are there, it could be that the templates are incorrectly cached, or it could also be something else totally.
To deploy your application, simply copy the contents of dist folder to wherever you are deploying. You don't need the node_modules, since they are only used for performing dev. tasks.
Also,
Your screenshots show a SignUpCtrl.js file at the app root. Yeoman scaffoldings, whichever one you are using, usually aren't designed to have script files at the app root. Try putting it back inside the scripts file first.
I know how to get the current directory from a Meteor package, but how do I get the path of a specific file in the project?
node's __dirname and __filename don't work in Meteor.
It is complicated.
meteor run copies your project files to a tree of directories inside <project-dir>/.meteor/local/build, reorganizes them in non-obvious ways (e.g.. the private subdirectory in the original tree becomes the assets subdirectory) and mixes it in with various npm modules to create a bundle that can be executed as a nodejs project. Indeed, to avoid duplications, there is a .gitignore file automatically set up in the .meteor directory that tells git, if you use it for version control, not to copy the .meteor/local directory.
The original project directory gets watched in case you change a file. The change then gets copied into the current project build directory and the project rebuilt.
If you deploy to a remote system, the build gets copied to a server and then run.
process is usually a defined global server-side object, and works according to the node.js API, because the meteor server code is ultimately running in node.js.
So you can run console.log(process.cwd()); in your server-side to obtain the current working directory for the server process, usually something like:
~/<meteor project directory>/.meteor/local/build/programs/server
This suggests that when meteor run is done locally, original project files are in ../../../../../, but don't use that as it may change in the future.
Instead, for the directory containing the original project files, you could use:
baseDir = process.cwd().replace(/\/\.meteor.*$/, '');
This will get the working directory, and truncate everything beginning with /.meteor
This won't work for a server deploy, though, because the original project tree is not needed on the server, only the build. Files that aren't intended to be client or server code could possibly be stuck in the private subdir, which as I mentioned becomes the assets subdir in the build. Ways to currently find files in the build is either manual inspection .meteor/local in a local run, or use of a JS library that calls or imitates gnu find.
Since you mentioned packages, I note that in the build, server-side package code finally ends up in:
~/<project-dir>/.meteor/local/build/programs/server/packages
and client side in:
~/<project-dir>/.meteor/local/build/programs/web.browser/packages