I have a TypeScript/React web app that uses ParcelJS and I would like to have either a step in the build or a simple way of using a resource file that holds git information.
Not sure if there is something that can generate the git information during the build, I'm using npm to launch parcel.
If parcel can load a resource file and make it accessible that could also work by having properties.
My end goal would be to display version and git commit point in the webapp.
I'm going to assume you're using parcel2 (I'm not sure this would be possible in parcel1).
Parcel2 uses babel to transpile typescript by default (through the #parcel/transformer-babel plugin). The babel configuration for this plugin can be over-ridden by simply including a .babelrc (for configuration relevant to only a subset of the project) or babel.config.json file (for configuration that will apply to the entire project). See this scenario matrix that I made in the process of fixing this bug for details about exactly what babel config files should be picked up by parcel. (The "proposed fixes" are merged into parcel2 as of the latest nightly release).
With the ability to supply your own babel configuration, you should be able to use this babel plugin to inject git repository information into your code.
(Since you're using typescript, you'll also need to make sure to include #babel/preset-typescript or #babel/plugin-transform-typescript in your babel config as well).
Related
The Webpack/Vue ecosystem is a very fragile one, with minor updates to loaders regularly breaking the build. It's basically a dedicated job to curate a working Webpack config together with a list of the exact dependency versions that are needed to make it work.
This Webpack config can easily be kept in a repository and then copied to many different projects and imported in their local webpack.config.js because webpack.config.js is just Javascript.
I'd like to do the same thing with package.json, i.e. have the curated list of dependencies in a separate file and when running npm install have them added to any other dependencies a project might have.
Do npm or yarn or any other external tools offer such a functionality?
Are you specifically trying to use a js file? If so, I don't have an answer, but if json is enough, you can just make an node package that just has the dependencies you want in it. Someone that includes your package will then pull in all the dependencies listed in your package because npm pulls in the dependencies of a project's dependencies.
Also see https://stackoverflow.com/a/55483109/14144258
When using the ui you have the option of installing dependencies and plugins.
I am confused about the difference between both of these.
For instance, I can install axios as a dependency and a plugin.
Do I need to do both? Why do one over the other?
My current understanding is that dependency is just that, it adds a package to your project while a plugin will add configuration as well.
Am I correct in thinking that?
A plugin is exactly what you described. It 'plugs into' another piece of software and adds functionality. A dependency on the other hand means that your software simply depends on something to function correctly - usually code.
In your axios example:
The axios plugin installs another prototype property on your Vue instance (this.$axios.. or whatever it is called) so it definitely adds a feature to Vue.
You could also only use Axios by itself and import it in the files you need
import axios from 'axios'. You don't add any feature to Vue itself - you just use another software within your app. Axios here is a dependency.
I will probably not be completely correct, but my understanding is
Plugins vs Dependencies
Command line
dependencies are installed via the command line as npm install <name> or npm install --save <name> to add the dependency to package.json
plugins are installed via the command line as vue add #scope/vue-cli-plugin-<name> or with the shorthand vue add #scope/<name>
Installation
dependencies are placed into your projects node_modules folder
plugins will invoke the generator.js script of the plugin being installed. This generator.js may add dependencies to package.json, add import statements to files in your project, add/alter existing components, or any of the various things listed under the generator api docs
Usage
dependencies will need to be imported into any file you use them in, or imported globally, before they are able to be used
plugins often will have already set up global imports, making them available in every file. Plugins will also often add additional scripts to package.json (which show up as tasks in the vue ui)
I am kind of new to PlayFramework 2 and can not figure out how to resolve play 2 application dependencies. I need to add dependency on a local module loaded in IntellijIdea, not a jar file or repository.
While adding module dependencies in Idea project setting works just fine and ide itself is able to resolve them (autocompletion, imports etc are working), when trying to run in play2, its compiler cannot resolve any dependencies.
I manually configured Build.scala (adding val appDependencies = Seq("" % "" % "")) but am puzzled as to what resolvers I should use. I cannot point to a jar file, as it is a work in progress and such a file should be updated too often. Doing so would defeat the whole purpose of managed dependencies.
Play's main build mechanism uses SBT, which needs to know how to find all sources required for the build. There are several options for this:
make your module an SBT project itself and publish it to your local ivy repository. However that might be somewhat complex at this stage, and would involve adding your local ivy repository to the resolvers and re-publishing every time you change something in the module
declare your module as a sub-project. Play's documentation describes the process of working with sub-projects, I think this is the way you'd like to try out since then the idea command on Play's console will generate the IntelliJ configuration for the main application and the module.
Here is my situation. I have a play app which uses the guice module. In order to work with the guice module:
I installed it using play install guice. This installs it in the $PLAY_HOME/modules which is fine by me. I don't want to edit the module files in any way whatsoever.
Then I declared the module in my dependencies.yml like so: - play -> guice 1.2
Within my app, I ran play dependencies, and this resoles the module just fine and creates a modules/guice-1.2 file that references the guice module.
The issue is that the content of that file is something like the following: /some-absolute-path/play-1.2.x/modules/guice-1.2.
That works fine when working locally for development. But when I want to move to a production server, with a different install of Play! (i.e. with a different absolute path to it) it will obviously fail.
So what's the best way to deal with this?
For now I've resorted to declaring the module in the application.conf file like this: module.guice=${play.path}/modules/guice-1.2.
Unfortunately the ${play.path} magic doesn't seem to work on those generated files.
By the way I use version 1.2.3 of Play!
you should try with ${application.path} in your dependencies.yml file, like in this example
require:
- play -> crud
- provided -> DateHelper 1.0
repositories:
- provided:
type: local
artifact: "${application.path}/jar/[module]-[revision].jar"
contains:
- provided -> *
see this question: How can I specify a local jar file as a dependency in Play! Framework 1.x
When you run in production you will either resync the dependencies (via play deps command) with the local installation of Play or in some scenarios you can precompile everything and then there will be no issues with the paths.
That second scenario is the one with Heroku, for example.
It's not answer to your question, but I have faced with same issue.
I don't want to call resync the dependencies on production.
I don't want to ask my team members, install special module.
I don't want to commit file containing absolute path with module location.
The only workaround that I find: do not install module in Play! application, just include jars which use this module manually. play-guice.jar should be included as #opensas suggested, aopalliance and com.google.inject as regular dependencies in dependencies.yml.
The funny thing, that resync dependencies is also deleting .svn files, so back-up its before calling this command.
this is an odd request but here is the scenario. I am writing custom maven plugins that basically manipulate build versions then will install or deploy the modified jar. The plugin is called both via command line and a build profile.
The plugins all have similar behavior, so the solution will work for all. Currently I am manipulating the project version in memory, via MavenProject.setVersion(newVersion);. This works and builds a local jar with the new version, but once the MavenInstaller executes the newVersion jar is installed in my local repo with the old version information and location. Is there a way I can prevent or override this behavior? The plugin is not using the Maven Installer or Deployer directly, and is just part of the build phase.
The file is executed as: mvn install -Pincrement and the increment profile is associated with the process-sources phase.
EDIT 1: I am looking into overriding the install/deploy lifecycle with a plugin that will basically handle what I plan on doing, while also still handling the normal behavior of install/deploy.
http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-override-default-lifecycle.html
EDIT 2: Following Edit 1 I was able to override a default lifecycle, in this case install and deploy with a custom solution. I do not like that it requires a custom package, so packaging tag no longer refers to the true packaging type and requires me to set an additional tag so that I can lookup the type.