I have done my first package for Deno, and then I publish it to deno.land/x/.
I would like to know if there is a way to Ignore some files and dires at the time of upload the package, example: [".github",".vim","test_deps.ts"].
Pretty much like .npmignore.
There is not currently a way to ignore files, but if you'd like to only include certain files, you can organize them separately in a subdirectory of your repository, and use that option when publishing your module:
The subdirectory that you choose in this step will become the root of the module's file hierarchy.
I have a Maven project written in Scala and deployed as a .jar. The project has the typical structure:
project-root
|__src
|__main
| |__scala
| |__resources
|
|__test
|__scala
|__resources
I have many hardcoded values in the application that I'd like to extract to a configuration file.
I could just create a text config file anywhere, read it from the code and use the parameters, but I'm looking for a best practice/approach. I'd like to take this things into account:
Is there a way such that I can change config values and not have to rebuild the .jar? That would be very practical.
Where would be the best location for the file? E. g. create a project-root/src/config directory and put the file there?
Any remarkable reasons about choosing among different formats? I'd go with XML, but I've seen quite a bit of YAML and HOCON around...
If you want to be able to change configuration values without building the jar, you will want your config external to the artifact. There are ways to modify the contents of the built jar but I don't think that is what you are wanting to do. If you want to have config you can change on the fly, keep it out of your jar and reference it on the Classpath at runtime.
If you want to keep it on your artifact, and rebuild when you change values, keep the configuration file in src/main/resources. Maven will automatically package it into your jar for you at the root of the archive.
As for format, that's probably personal preference. Reading YAML usually requires another library such as snakeyml to parse effectively, so if you are trying to keep your library light on dependencies, maybe look at .config or .properties files instead. Otherwise, XML and YAML are always nice for complex configuration.
Since I first saw a dist/ directory in many open source projects, usually on GitHub, I've been wondering what it means.
With dist, vendor, lib, src, and many other folder names that we see quite often, I sometimes wonder how I should name my own folders.
Correct me if I'm wrong!
src: Contains the sources. Sometimes only the pure sources, sometimes with the minified version, depends on the project.
vendor: Contains other dependencies, like other open source projects.
lib: Good question, it's really close to vendor actually, depending on the project we can see one or another or both...
dist: From what I saw, it contains the "production" files, the one we should use if we want to use the library.
Why is open source so confusing? Isn't it possible to do things clearer? At least per language because some languages use specific names.
To answer your question:
/dist means "distributable", the compiled code/library.
Folder structure varies by build system and programming language. Here are some standard conventions:
src/: "source" files to build and develop the project. This is where the original source files are located, before being compiled into fewer files to dist/, public/ or build/.
dist/: "distribution", the compiled code/library, also named public/ or build/. The files meant for production or public use are usually located here.
There may be a slight difference between these three:
build/: is a compiled version of your src/ but not a production-ready.
dist/: is a production-ready compiled version of your code.
public/: usually used as the files runs on the browser. which it may be the server-side JS and also include some HTML and CSS.
assets/: static content like images, video, audio, fonts etc.
lib/: external dependencies (when included directly).
test/: the project's tests scripts, mocks, etc.
node_modules/: includes libraries and dependencies for JS packages, used by Npm.
vendor/: includes libraries and dependencies for PHP packages, used by Composer.
bin/: files that get added to your PATH when installed.
Markdown/Text Files:
README.md: A help file which addresses setup, tutorials, and documents the project. README.txt is also used.
LICENSE.md: any rights given to you regarding the project. LICENSE or LICENSE.txt are variations of the license file name, having the same contents.
CONTRIBUTING.md: how to help out with the project. Sometimes this is addressed in the README.md file.
Specific (these could go on forever):
package.json: defines libraries and dependencies for JS packages, used by Npm.
package-lock.json: specific version lock for dependencies installed from package.json, used by Npm.
composer.json: defines libraries and dependencies for PHP packages, used by Composer.
composer.lock: specific version lock for dependencies installed from composer.json, used by Composer.
gulpfile.js: used to define functions and tasks to be run with Gulp.
.travis.yml: config file for the Travis CI environment.
.gitignore: Specification of the files meant to be ignored by Git.
To answer your original question about the meaning of the dist folder:
The shortform dist stands for distributable and refers to a directory where files will be stored that can be directly used by others without the need to compile or minify the source code that is being reused.
Example: If I want to use the source code of a Java library that someone wrote, then you need to compile the sources first to make use of it. But if a library author puts the already compiled version into the repository, then you can just go ahead. Such an already compiled version is saved into the dist directory.
Something similar applies to JavaScript modules. Usually JavaScript code is minified and obfuscated for use in production. Therefore, if you want to distribute a JavaScript library, it's advisable to put the plain (not minified) source code into an src (source) directory and the minified and obfuscated version into the dist (distributable) directoy, so others can grab the minified version right away without having to minify it themselves.
Note: Some developers use names like target, build or dest (destination) instead of dist. But the purpose of these folders is identical.
Summary of the folders:
bin: binaries
contrib: contributions to the project
dist: -- see 1. and 2.
doc/s: documentation
include: headers (C/C++)
lib: libraries (C/C++)
man: short for man/manual pages (Unix/Linux), c.f. man(1)
src: source
"/dist means "distributable", the compiled code/library." ref.
"The shortform dist stands for distributable and refers to a directory where files will be stored that can be directly used by others without the need to compile or minify the source code that is being reused." ref.
Actually! "dist folder" is the result you get after modifying a source code with "npm run build" or "ng build" or "ng build --prod" for production.
Meanwhile! After getting "dist folder" there might still be few things that you still need to do depending on your project type ✌️
I have a Play 2 application that uses some external Java libraries. Some of these (e.g. the Paypal merchant sdk) depend on having a properties file for configuration (e.g. sdk_config.properties) which I have put into the conf directory.
When deploying this application to a different environment using play dist is there a sensible way to swap out properties files for each environment? For the main configuration in application.conf this is straightforward e.g. start -Dconfig.resource=prod.conf, but I am not sure how to do something similar for the properties files.
The support for specifying config.resource (and a lot of other nice stuff) is built into the typesafe config lib that comes with play. Other third party libs that depend on properties files on the classpath may or may not accept something like that, so if you are lucky then there is a lib specific way to point it to a separate config file.
If they do not then the only option is to somehow provide a different file on the classpath for the different environments. This could basically be done in two ways:
A. To not ship the file with the artifact and instead provide it per environment and add that on the classpath when starting play.
B. To create different artifacts for the different configurations, this would require you to customize dist to create one artifact per distinct env.
I would go for A since it allows there to be one artifact that can be run anywhere, but it might add some annoyances to running the app in a dev env etc.
I built a universal tarball using sbt-native-packager.
How do I load configuration files like c3p0 and application.conf from /etc/myapp or anyother custom location when I start the app.
I don't want the config files to be part of the distribution tarball itself.
I believe you can use typesafe config's "include" feature to grab from a direct location.
See https://github.com/typesafehub/config#features-of-hocon
That said, this would require you to create different configurations based on where you're installing, if you wanted a global file as the config file.