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.
Related
I have received an entire source archive for a Yocto-build. But I can't figure out how to install it.
The archive is a zip file containing three .tar.xz files with names like machine-name-allarch-poky-linux.tar.xz, where each of these files contain a directory structure like sources/allarch-poky-linux/ followed by many different folders with all different source packages.
The file structure is just like what can be found here:
https://download.automotivelinux.org/AGL/release/lamprey/12.1.0/raspberrypi4/deploy/sources/
As in above, the final directories contain a .tar.gz with all source code etc for each package, and very often there is also a couple of patches and other miscellaneous files.
Probably the archive was created with the archiver class.
But the manual does not say anything about what the user (in this case, me) shall do to install the created archive.
It seems to be related to the DL_DIR, but the file structure doesn't really comply with what the DL_DIR usually contains (only tarballs, no loose patches etc. and the tarballs are not in sub-directories as in the archive).
How do I go about to get Yocto to use these archives?
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.
I've created a new foundation project using the foundation new myproject --libsass method.
Its just a simple static index.html (for the purpose of this question).
I've deployed it to a live server now, and I am wondering about the best way to structure this. I have omitted the node_modules & scss directories, and i'm left with the following:
bower_components/
css/
js/
index.html
bowerrc
bower.json
Gruntfile.js
humans.txt
package.json
README.md
bower_components is needed in its current form, unless I shuffle some files around, which is what I intend to do, but I'm checking if there is a better way of doing this, and that I haven't missed some magic terminal command to deploy to production.
As msturdy suggested in the comments, grunt is the way to go here. There are a lot of plugins out there, see a list on the official page.
If you want to have grunt "compile" your project into one specific folder which you can then for example push to a deployment server, you should do several things in grunt:
compile your scss
minify your javascript, that is making the files smaller, see jscompress for a demo of what it is. All your js-files from /bower_components which you include in your project should be in a vendor.js which is loaded first, and then a second js-file should contain your custom js from /js
save everything into a deployment folder.
(optional) automatically deploy to a server.
Take a look at these grunt tutorials for setting up your gruntfile.js, you'll want to have two tasks, one for just quickly compiling your scss, one for the whole deployment process:
grunt is not weird and hard
official tutorial
sitepoint tutorial
They show you how to do certain things and definitely how to write the gruntfile. Plugins you might want to use apart from your current libsass plugin are uglify and any plugin that lets you deploy your code via git, ftp or anything else. You can download all these plugins via npm by adding them to your package.json and doing npm install, refer to their websites for exact usage instruction.
I would like to use NuGet packages for building packages for core helper libraries which I would like to add as source files into other projects. I want to use source files instead of libraries for several reasons, the main one being that I need them in SharePoint Projects, which is on the one hand much easier to deploy than additional libraries, and on the other hand helps to reduce version conflicts.
I know that I can add the source files as content to NuGet Packages, which would install them with the package. But this won't work together with package restore, and I don't want to have these files checked into source control in all projects.
Is it somehow possible to make a NuGet package which doesn't copy the files to the project, but instead adds file links, which point back to the file in the package folder, to the project? I think this approach would solve my use case.
Thanks
pascal
It is possible to add linked files with the use of PowerShell scripts, for example with this NuGet script: http://www.nuget.org/packages/Baseclass.Contrib.Nuget.Linked/
Trying to understand how EDE works by using it to generate Makefiles for
a project directory that contains several targets under a specific
hierarchy. I'm not having any luck, and the info pages don't seem to
answer my question.
My directory structure looks something like:
(The asterix (*) marks files containing main() functions)
research/
flow/
flow.cpp
flow.hpp
program.cpp *
samples/
sample1.yuv
utils/
yuvreader.cpp
yuvreader.hpp
tests/
yuvreader_test.cpp *
I want to create EDE project(s) with one or more subprojects; or maybe I
just want one or more targets...?
flow's program.cpp requires flow/ and utils/ sources, but yuvreader_test
only requires utils/ sources.
I did ede-new in the root directory, and all subdirectories. I also did ede-new-target in the root directory, but when adding source files in subdirectories, it does not recognize the target I created.
I would appreciate it if someone could point me to some more complicated
Project.ede files for something like I'm trying to do. You can guess
that I have more subdirectories containing class code files, some of
which have standalone programs that use that code; also I have more test
code under tests/. Any example files/command workflows would be
appreciated.
The EDE feature that will generate Makefile or Automakefiles has a few more constraints than either Make or Automake. For example, the files belonging to a target must be in the same directory as the project containing the target. In your example, you would probably have no projects in your root directory.
To bring multiple sources together into a single program, a simple mechanism is to have each subdirectory create an archive (.a) or a shared lib (.so) that is linked together in your program.
If that is too constraining, you can also write your own automake files, and EDE will read those directly, so you can have a more complex build procedure as needed.
The CEDET distribution uses EDE as its build process, so you could look at that as a complex example. It doesn't build C++ files though, so it may not be as helpful as you would like.