I recently upgraded our dojo build from dojo 1.9.1 to 1.9.10, and for some reason now I am seeing *.consoleStripped.js files left over from the optimizer. It's great that it's removing the console statements, but I would expect these would be intermediate files not included in the final build product. When I look at util/build/transforms/optimizer/closure.js, I don't see any code to remove the files. I can manually remove them with a find blah blah | xargs rm, but is there a setting to remove these files after they are used to create the final minimized files? I can't seem to find one. Or is there some reason that I am missing to deploy these "consoleStripped" files alongside the other files (mimized, uncompressed, and map)?
You can use:
stripConsole: "normal"
to strip from your build all console.
Use:
layerOptimize: "closure"
to switch to closure if you need too.
Full documentation related to Dojo Build Optimization can be found here:
https://dojotoolkit.org/documentation/tutorials/1.10/build/
Edit:
Dojo build cannot delete you *.consoleStripped.js for that you need to use grunt, gulp or another external tool.
I believe that dojo-build uses ShrinkSafe by default, and not Google Closure (ref).
Either way, both have their codes hidden away in Java .jar files.
I remove these files by adding the below to the very end of my build script - ensuring that I have 'cd' to the distribution folder first.
find . -regextype posix-extended -regex "(.*\.bak|.*\.consoleStripped\.js|.*\.uncompressed\.js|.*\.map)$" -type f -delete
Related
We have unique requirement such that we need to deliver only those binaries and libraries to clients which have undergone any change between last buld and the latest build. So far we had been doing this manually. Is there automated way of doing this on linux cpp builds
How about using a shell script to list files that have been modified since the last build, and copy them to a temp directory? You can use "find" in Linux to look for files that have been modified since a specific date and do something with these files:
find [directory] [type of file] [Time of the last data modification] [action]
For example:
find . -type f -newermt '1/5/2022 00:00:00' -exe cp {} /dirToModifiedFiles
I'm the author of a utilty that makes compressing projects using zip a bit easier, especially when you have to compress regularly, such as for updating projects submitted to an application store (like Chrome's Web Store).
I'm attempting to make quite a few improvements, but have run into an issue, described below.
A Quick Overview
My utility's command format is similar to command OPTIONS DEST DIR1 {DIR2 DIR3 DIR4...}. It works by running zip -r DEST.zip DIR1; a fairly simple process. The benefit to my utility, however, is the ability to use a predetermined file (think .gitignore) to ignore specific files/directories, or files/directories which match a pattern.
It's pretty simple -- if the "ignorefile" exists in a target directory (DIR1, DIR2, DIR3, etc), my utility will add exclusions to the zip -r DEST.zip DIR1 command using the pattern -x some_file or -x some_dir/*.
The Issue
I am running into an issue with directory exclusion, however, and I can't quite figure out why (this is probably be because I am still quite the sh novice). I'll run through some examples:
Let's say that I want to ignore two things in my project directory: .git/* and .gitignore. Running command foo.zip project_dir builds the following command:
zip -r foo.zip project -x project/.git/\* -x project/.gitignore
Woohoo! Success! Well... not quite.
In this example, .gitignore is not added to the compressed output file, foo.zip. The directory, .git/*, and all of it's subdirectories (and files) are added to the compressed output file.
Manually running the command:
zip -r foo.zip project_dir -x project/.git/\* -x project/.gitignore
Works as expected, of course, so naturally I am pretty puzzled as to why my identical, but dynamically-built command, does not work.
Attempted Resolutions
I have attempted a few different methods of resolving this to no avail:
Removing -x project/.git/\* from the command, and instead adding each subdirectory and file within that directory, such as -x project/.git/config -x project/.git/HEAD, etc (including children of subdirectories)
Removing the backslash before the asterisk, so that the resulting exclusion option within the command is -x project/.git/*
Bashing my head on the keyboard in angst (I'm really surprised this didn't work, it usually does)
Some notes
My utility uses /bin/sh; I would prefer to keep it that way for maximum compatibility.
I am aware of the git archive feature -- my use of .git/* and .gitignore in the above example is simply as an example; my utility is not dependent on git nor is used exclusively for projects which are git repositories.
I suspected the problem would be in the evaluation of the generated command, since you said the same command when executed directly did right.
So as the comment section says, I think you already found the correct solution. This happens because if you run that variable directly, some things like globs can be expanded directly, instead of passed to the command. And arguments may be messed up, depending on the situation.
Yes, in that case:
eval $COMMAND
is the way to go.
I'm using ag to search a git repo. It doesn't find matches under my node_modules subdirectory. Why not, and how can I control this behavior?
It turns out that ag honors the contents of the .gitignore file by default. So if node_modules is in .gitignore, ag won't search it. This is all sensible behavior, but difficult to debug if you aren't expecting it. Hopefully this post will help.
There's a good summary at the end of man ag:
IGNORING FILES
By default, ag will ignore files whose names match patterns in .gitig-
nore, .hgignore, or .agignore. These files can be anywhere in the
directories being searched. Ag also ignores files matched by the
svn:ignore property if svn --version is 1.6 or older. Finally, ag looks
in $HOME/.agignore for ignore patterns. Binary files are ignored by
default as well.
If you want to ignore .gitignore, .hgignore, and svn:ignore, but still
take .agignore into account, use -U.
Use the -t option to search all text files; -a to search all files; and
-u to search all, including hidden files.
For my purposes ag -t seems to work well.
I want to change in a project from javascript to typescript.
Therefore i want to change the extensions of all files from *.js to *.ts recursively.
How do i accomplish it with webstorm?
There's no way to rename multiple files in the project in WebStorm, unfortunately.
You can vote for the related issue on JetBrains issue tracker.
Do it outside of Webstorm on linux (or Windows git bash) with ..
cd my-folder
find . -name "*.t1" -exec bash -c 'mv "$1" "${1%.t1}".t2' - '{}' \;
courtesy of Recursively change file extensions in Bash
This works recursively, make sure you cd to the correct folder first (typically your project root folder).
I have a TeamCity Build Configuration that includes the following to publish artifacts:
Source\Builder\bin\Release\*.dll=>release
This works fine, however I am wanting to exclude one dll (there are quite a few) and have read that you can use + & - operators to do this. Something along the lines of:
+: Source\Builder\bin\Release\*.dll=>release
-: Source\Builder\bin\Release\Builder.*
As soon as I add these in, no artifacts are published and I get the following error in the build log (looks like it is counting the + as part of the path):
[Publishing artifacts] Collecting files to publish [+:Source\Builder\bin\Release\*.dll=>release]
[Publishing artifacts] Artifacts path +:Source/Builder/bin/Release/*.dll not found
I am using version 7.1.1, anyone any ideas (I am not sure whether these operators are even valid). I have seen a solution with MSBuild but am surprised this functionality is not available.
Thanks in advance.
I don't believe you can.
However, if you are using the artifacts in another build configuration as an artifact dependency, you can exclude a particular file there.
When you set up the dependencies, you can specify a negative operator like this:
+:release/**=>Dependencies/SomeProject
-:release/SomeBinary.dll
It is a horrible hack, but one way you could get it to work would be to set up a new build configuration which gets the dependencies as an artifact dependency, excluding the one binary, and then publishes its own artifacts.
As in, create a new build configuration and publish:
Dependencies/SomeProject=>release
Then reference the artifacts from this build configuration instead of the other one.
A little bit late for the party, but there is still no fix...
I ended up adding a last build step to the project. It is command line > custom script. Then I used this commands to remove the files that I didn't want in the artifacts. This runs just before artifacts collection.
del /S /Q "src\apps\*.xml"
del /S /Q "src\apps\*.pdb"
Explanation for del command
/S Delete from all Subfolders (DELTREE)
/Q Quiet mode, do not give a Yes/No Prompt before deleting
* Match any characters
Our current options are to vote for this feature request at
http://youtrack.jetbrains.com/issue/TW-5244 and fail back to workarounds.
TeamCity artifact paths combine folders question hints that the same target folder can be reused for multiple path patterns.
TeamCity docs also state that
TeamCity will create directories starting from the first occurrence of
the wildcard in the pattern.
So in many cases it's possible to inverse exclusion problem to multiple inclusions.
For example, instead of lurking how to exclude -:**/.svn from my templates I was able just to filter them by extension:
templates/**/*.vm => templates
templates/**/*.xsl => templates