Is there any way to configure ember-cli globally to use yarn on new projects? A ember new <project-name> should use yarn without providing --yarn flag.
Background information
Recent versions of ember-cli uses yarn if
a yarn.lock file is present in projects root or
if --yarn flag is provided.
Since there can't be a yarn.lock before creating a new project, --yarn flag has to be used always on ember new <project-name> if yarn should be used.
If I got it correctly, ember-cli uses yam for configuration by a .ember-cli file. But as far as I know, this one is also only available in a existing project and could not set global configuration.
Motivation
I could of course always remember to use --yarn flag on creating a new project, but often I forget about it and have to abort the command. I prefer yarn also on init cause it's a lot faster. Also if it's not used already on project generation, yarn.lock file is not part of the initial commit. It's simply annoying.
.ember-cli can be configured both globally and on a per-package basis
Global configuration is located in $HOME/.ember-cli
Ember CLI’s runtime is configurable via a file named .ember-cli. The
JSON-formatted file, which must be placed in your home directory, can
include any command-line options whose names must be in camel case
form
Project only changes will be located in /path/to/project/.ember-cli.
It is now also possible to override command line options by creating a
file in your app’s root directory called .ember-cli and placing
desired overrides in it.
Since you're wanting to have all newly created projects to use yarn, add the following to $HOME/.ember-cli
"yarn": true
Related
Does anybody know how to use workbox without getting it from the CDN? I tried this...
add workbox-cli to my dependencies:
"workbox-cli": "^3.6.3"
which gets me all of the following dependencies
$ ls node_modules | grep workbox
workbox-background-sync
workbox-broadcast-cache-update
workbox-build
workbox-cacheable-response
workbox-cache-expiration
workbox-cli
workbox-core
workbox-google-analytics
workbox-navigation-preload
workbox-precaching
workbox-range-requests
workbox-routing
workbox-strategies
workbox-streams
workbox-sw
Then I replaced this line in the examples
importScripts('https://storage.googleapis.com/workbox-cdn/releases/3.6.1/workbox-sw.js');
with this
importScripts('workbox-sw.js');
after copying node_modules/workbox-sw/build/workbox-sw.js to the public folder
But now I realise by looking at the network tab, that that file still gets all the other modules from the cdn
(I thought it would be build with everything inside it.)
Can anybody tell me if there is an npm package somewhere that already has everything inside it? Or should I copy the modules I need from the npm folder, and somehow tie them all together myself? Or do I have to use the webpack plugin? (which I guess will only bundle the modules that I use)
(Update: Workbox v5 makes the process of using a local copy of the Workbox runtime much simpler, and in most cases, it's the default.)
There's one more step that's required. The "Using Local Workbox Files Instead of CDN" has the details:
If you don’t want to use the CDN, it’s easy enough to switch to
Workbox files hosted on your own domain.
The simplest approach is to get the files via workbox-cli's
copyLibraries
command
or from a GitHub Release, and then tell workbox-sw where to find
these files via the modulePathPrefix config option.
If you put the files under /third_party/workbox/, you would use them
like so:
importScripts('/third_party/workbox/workbox-sw.js');
workbox.setConfig({modulePathPrefix: '/third_party/workbox/'});
With this, you’ll use only the local Workbox files.
I'm developing a library of components, which is using Lerna. This means each component directory has a package.json file. I also have a dist in each of them. That's where the bundle yields to, obviously. My issue occurs while developing. My import statements encounter the package.json and try to get the source from dist instead of an index.js, where the source lives. How can I mitigate that so the require process avoids the package.json?
Ok, apparently I found my answer in Webpack docs, but it wasn't that easy. You have to add a module key (in addition to main) to let the Webpack resolver know which source to load while in modules environment (development).
See here: https://webpack.js.org/configuration/resolve/#resolve-mainfields
I'm learning Aurelia via the TypeScript / ASP.NET Core skeleton navigation app. Everything runs fine in its default state. To test the exported production bundle, I run the Gulp Export task, then publish the app via Visual Studio project publish to a local folder, then replace the published wwwroot folder with the wwwroot folder from within the "export" folder, then use dotnet from the command line to run the app.
Things break if I have any source modules in a subdirectory. For example, I moved the welcome.ts/html component files into "/src/Pages" and adjusted its route moduleId in app.ts accordingly to "./pages/welcome". The unbundled app then still runs up fine, but when I try the exported version, I get a request being made by SystemJS to http://localhost:5000/dist/pages/welcome.js which 404s (as you'd expect).
I can see the contents of the welcome component in the app-build.js file, and the config.js file within the export folder contains the expected file paths, i.e. it has "Pages/welcome...".
I have read this seemingly similar issue:
https://github.com/aurelia/bundler/issues/131
But setting depCache to false made no difference in my case. Why is SystemJS trying to load this module separately from outside of the bundle?
I was able to reproduce this error locally.
Presuming that you have a Windows environment, it will be a case-sensitivity issue.
After renaming [P]ages folder to [p]ages, bundled version works as expected.
On the filesystem there is a [P]ages/welcome.js viewmodel, but [p]ages/welcome has been defined as moduleId.
Unbundled mode: Windows filesystem is case-insensitive, which behaviour can be misleading by loading [P]ages/welcome.js correctly.
Bundled mode:
Based on file path, bundling process embeds[P]ages/welcome.js as [P]ages/welcome module.
But, according to the route config, SystemJS will be looking for [p]ages/welcome module within app-build.js.
My recommendation would be to use lowercase folder/filenames whenever it's possible.
I'm currently experimenting with ACI construction for rkt-containers. During my experiments I've built some containers especially for the use as a dependency. I now want to use these .aci images as a dependency for other images. As these files are fetched by name (for example "quay.io/alpine-sh"), I wonder if there is a way to refer to actual local .aci files.
Is there a way to import these .aci files from the local filesystem or do I have to set up a local webserver to serve as a repository?
Dependencies in acbulid (at least till version 0.3) can be defined only as http-links,
so you need to make your aci available through http to use it as dependency in acbuild.
It's not so hard to publish your aci to make it available through http. Image archive can be actually hosted on github or bitbucket.
The recent versions of acbuild seem to support it
since the relating issue (cache dependencies across acbuild invocations #144) is closed.
Cached ACI's are stored in directories depstore-tar and depstore-expanded inside $CONTEXT_ROOT/.acbuild. If we save somehow content of those directories between acbuild init,
acis won't be downloaded over and over again.
When i played with acbuild i was so annoyed that acbulid redownloads dependencies on every build.
I've written script https://bitbucket.org/legeyda/anyorigin/src/tip/acbuild-plus
which configures symbolic links inside $CONTEXT_ROOT/.acbuild to point to
persistence directories inside /var/lib/acbuild/hack. The usage is simple:
acbuild begin
acbuild-plus init target
After that all dependencies will be cached by acbuild.
You can also manually install aci-file to be available to acbuild.
This is as simple as
acbulid-plus install <your-image.aci>
I've tested the script with acbuild v0.3.0.
You can get an example of using it in the Makefile next to acbuld-plus in the repository.
I would like to be able to run the java program in a specific directory. I think, that it is quite convenient to parametrize working directory, because it allows to easily manage configurations.
For example in one folder you could have configuration for test, in other you could have resources needed for production. You probably think, that there is option to manipulate classpath for including/exluding resources but such solution works only if you are interested in resources stored in classpath and referencing them using Classloader.getResource(r). But what if you have some external configuration and you want to access it using simple instructions like File file = new File("app.properties");?
Let's see ordinary example.
Your application uses app.properties file, where you store credentials for external service. Application looks for this file in working directory, because you uses mentioned File file = new File("app.properties"); instruction to access it. In your tests you want to use app.properties specific to your tests. In you integration tests you want to use app.properties specific to another environment. And finally when you build and release application you want to provide other app.properties file. All these resources you want to access always in the same way just by typing File file = new File("app.properties"); instead of (pseudo code):
if(configTest)
file = File("testWorkDir/app.properties");
else if(config2)
file = File("config2WorkDir/app.properties");
else
file = File("app.properties");
or instead of using resources in classpath
this.getClass.getClassLoader.getResource("app.properties");
Of course you are clever programmer and you use build tool such maven, gradle or sbt :)
Enought at the outset. At least The Question:
Is there a way to set working directory in java and if yes how to configure it in build tools (especially in sbt)?
Additional info:
changing 'user.dir' system property is not working (I've tried to change it programaticly).
In sbt changing 'working directory' via baseDirectory setting for test changes baseDirectory which is not base dir in my understangind and it is not equal new java.io.File(".").getAbsolutePath.
Providing environment variable like YOUR_APP_HOME and referencing resources from this path is feasible but require to remember about this in your code.
In sbt changing 'working directory' via baseDirectory setting for test changes baseDirectory which is not base dir in my understangind and it is not equal new java.io.File(".").getAbsolutePath.
I'm not sure what the above statement means, but with sbt you need to fork to change your working directory during the run or test. This is documented in Enable forking and Change working directory.
If you fork, you can control everything, including the working directory.
http://www.scala-sbt.org/0.13.5/docs/Detailed-Topics/Forking.html
Example code:
fork in run := true
baseDirectory in run := file("/path/to/working/directory/")