I've been using dart projects in order to practice dart programs and wondered why there are two folders bin and lib both can contain dart files.
I did some research about this and they said bin folder is for creating console application but that didn't help me. I don't have a clear idea about console application.
and why should I bother about these folder if I'm only using dart projects just for practicing dart language?
The bin folder is where you put the public entrypoints for your project to compile it to executable binaries for console applications.
If you are just practing dart code, you can leave it there and just use the lib folder. Just make sure you'll have a file inside bin with the same name as the project/package you created (defined in pubspec.yaml) and a main() function, so you can use dart run.
The lib folder is for all the other code you write. You can add in there all your classes files of your project as a additional code to be called by the files from the bin folder. Or you can use just the lib folder to write a package/library for other apps, without needing to have a bin folder.
But the bin folder can have a file for each command, with a main() inside each file.
For example, you could have in it bin/sum.dart and bin/subtract.dart. Then you can compile each to a executable binary (sum.exe and subtract.exe) to use it as a command-line/console program.
To run each file without compiling just use dart run :COMMAND (in the example above, dart run :sum).
If you want to know more about it, see the documentation explaining how to compile and how to write a package that has a command-line tool
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.
How do I refer to files generated by a sourceGenerators sbt task? I know that the source file is deposited to target/scala-<version>/src_managed/path/to/File.Scala but I don't know how to reference it in my project. Any ideas?
/server
/app
/models
Driver.scala (can't use MyGeneratedCode here)
/project
/src/main/scala/
ModelGenerator.scala (the code used to create MyGeneratedCode.scala)
/target/scala-2.12
/classes
/src_managed
/main/generated/
MyGeneratedCode.scala
The generate file works as any normal Scala file but on a fancy folder so it is not tracked by git (or any other VCS).
As any Scala file, it should had a package whatever statement at the beginning, from which you can latter import your classes (import whatever._). Usually the package name matches the directory structure, but they do not have to (specially since it is just generated file).
If it does not have a package, all its members probably resides on the __root__ package. But that probably would cause troubles, I would suggest editing your generator to add a package statement instead.
I'm trying to create a Dart backend framework that developers can download as a dependancy and have the basic folder structure, Dart files and such generated for them in their own project. From what I understand, downloading a dependancy package only places files inside the package directory/ies (although, I may be wrong).
To get around this, I believe Dart can be used like a Bash script, and can place files in the project directory automatically through running the package's bin files in the terminal (illustrated in the Running a script in a dependency https://www.dartlang.org/tools/pub/cmd/pub-run.html).
Would this be the best way to achieve the desired result? Or is there an easier way to download a framework as a project template? (I'd also like to place similar scripts for generating controllers and such in the tools directory, and don't know if keeping this framework as a dependancy would be necessary after 'install').
Thank you for reading.
You can use pub global activate some_package to be able to use pub global run some_package:some_script or just some_script to allow to run a script contained in a Dart package without adding it to the dependencies.
I think this is the best way to distribute it.
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 ✌️