I was looking through my package-lock.json and I came across this requirement:
"requires": {
"bootstrap": ">=4.5.3 <5.0.0",
}
What does it mean to have two version expressions in one line like this?
I'm writing something to compare package versions and I don't know how to interpret it.
In the context of a package requirement, "bootstrap": ">=4.5.3 <5.0.0" means that the package requires a version of bootstrap that is greater than or equal to 4.5.3 and less than 5.0.0. In this context it would function the same as ^4.5.3 but you could use this functionality to specify a larger range if needed. Eg: "bootstrap": ">=4.5.3 <5.3.7" which would make the package compatible with any version of bootstrap from 4.5.3 up to (but not including) 5.3.7.
Related
Laravel 8 - Bootstrap 4
I have two Laravel projects. One created and running in docker, the other created and running in Vagrant/Homestead. The setups are almost the same otherwise.
However, in my vagrant/homestead project, when I use variables in my app.scss file like these:
$theme-colors: (
"blue": #007bff,
"indigo": #4B0082,
"purple": #6d388c,
"pink": #e83e8c,
);
What compiles into my app.css file, is duplicated for the items above, like this:
:root {
--blue: #3490dc;
--indigo: #6574cd;
--purple: #9561e2;
--pink: #f66d9b;
--blue: #007bff;
--indigo: #4B0082;
--purple: #6d388c;
--pink: #e83e8c;
}
With my colors lower in the file. The end result is the same, as the lower variables take precedence, and they aren't double processed into the classes where they are included either.
It seems something is wrong, as this does not happen in my project on the docker install. Is it possible that the mixin (or...) rules changed to now include the duplicates? Hard to guess that is true.
I don't believe docker or vagrant has anything to do with this, I'm just using those specifics to keep clear which is which.
Any ideas? Thanks.
Is it possible to add a minimum version to a module listed in the depend section of a META6.json file?
It uses the same syntax as the Version class. You can use, for instance, v1.0+, or, in META6.json, simply "1.0+"
To declare a dependency on Foo of version 1 or higher one would do the same as if one was asking zef to install Foo:ver<1.0+>:
zef install "Foo:ver<1.0+>"
"depends" : [
"Foo:ver<1.0+>"
]
Long form identities use version literals for api and ver attributes, and strings for any other (such as auth, file, name, etc). So to describe such a dependency you should write it the same way you would if you were useing it using the literal form :foo<...> ala use Test:ver<6.d+>. This is opposed to :foo(...) form which can run anything, e.g. use Test:ver(do { say 42; v6.d+ }), which would allow arbitrary code execution by just searching for dependencies and thus is not a valid way to describe something in a META6.json
I am trying to get Atom to work with LESS and I can't find the correct way.
This is my folder structure:
/css/main.less
/css/partials/base.less
/css/partials/forms.less
...
I want to build main.less every time I save a partial but not build the partial itself. How can I do that? I think I tried all packages related to LESS and none of them solved my problem.
Ok, I found why I wasn't able to make it work.
I am using the package atom-less which I tried before. The only thing I did different is restarting Atom after package installation.
Following the instructions of the package is enough to make it work. In my case:
comment on the first line of main.less:
// "out": "main.css", "sourcemap": false, "compress": true, "autoprefixer": false
comment on the first line of one partial:
// "main": "../main.less"
For my application, I created 4 components, and want to 'install' only the applications and their docs. According to https://cmake.org/Wiki/CMake:CPackConfiguration, if in my config file I have the line
set(CPACK_INSTALL_CMAKE_PROJECTS "${CMAKE_CURRENT_BINARY_DIR};${CMAKE_PROJECT_NAME};ALL;/")
then all the four components are installed. If I use the component names instead like
set(CPACK_INSTALL_CMAKE_PROJECTS "${CMAKE_CURRENT_BINARY_DIR};${CMAKE_PROJECT_NAME};apps docs;/")
I receive a package with no component name appended, and it contains the top level requested directory but no files at all. If I provide only one component like
set(CPACK_INSTALL_CMAKE_PROJECTS "${CMAKE_CURRENT_BINARY_DIR};${CMAKE_PROJECT_NAME};apps;/")
the package name does not contain the name of the component, but the files are generated in their right position.
What do I wrong?
EDIT: Just to add more strange things:
For the ALL case 4 files with names install_manifest_+comp name are created. For the second case I have install_manifest_apps docs.txt of zero length, and for the third case I have install_manifest_apps.txt, with the right content.
It seems to me that the macro can only accept one argument which can be either ALL or a component name; this means it cannot be used to install a 2-component system.
Moreover: if I use a component name, make package only produces that one package, without appending the component name, but with the right content. Till now I guessed that make install and make package are independent.
Set multiple values to CPACK_INSTALL_CMAKE_PROJECTS, one for each component you want to include:
set( CPACK_INSTALL_CMAKE_PROJECTS
"${CMAKE_CURRENT_BINARY_DIR};${CMAKE_PROJECT_NAME};apps;/"
"${CMAKE_CURRENT_BINARY_DIR};${CMAKE_PROJECT_NAME};docs;/"
)
Is it possible for me to declare a dependency using a dynamic revision while restricting the status of the retrieved artifact? For example, I want to define a version range, something like "[1.0,1.1[", but I don't want artifacts with a status of integration, only milestone or release. So I want version 1.0.5 if it has a status of "release" even if there's a version 1.0.6 with a status of "integration."
I know about latest.status, but that's not really what I want: I need to define an upper and lower limit on the revision.
Maybe the solution is to define your own version-matcher see http://ant.apache.org/ivy/history/latest-milestone/settings/version-matchers.html
I used it (in ivysettings.xml) to make this:
<!-- Matcher for build with given build number
It assumes the version number is on the form
#.#__.# where the lastet '.#' is the build number. -->
<version-matchers usedefaults="true">
<pattern-vm>
<match revision="build_number" pattern="[\d\.]+\.${buildnumber}" args="buildnumber" matcher="regexp"/>
</pattern-vm>
</version-matchers>
You can call it in you build script by setting the revision attribute like 'revision="build_number(${prop.buildnumber})"'
Thanks for asking this question, rsteele. I had a similar question and here is the solution I am using. It works if your range corresponds to sub-revisions:
The easiest way to present this is with an example:
<dependency org="com.acme" name="wigdet" branch="1" rev="latest.milestone">
1/ivy-1.0.xml: status="integration"
1/ivy-1.1.xml: status="milestone"
1/ivy-1.2.xml: status="integration"
The dependency resolves to 1.1.
This works for me but I am not entirely happy with it and I hope someone can point out a better way or poke holes in it:
branch seems appropriate because com.acme actually has a branch in version control which corresponds to version 1.
on the other hand branch seems inappropriate because "1" is part of the revision, and perhaps branch is more useful in other ways.
this doesn't solve the more general problem posed by rsteele.