PROBLEM
We have a site on Bootstrap 3.0.2 which won't compile in Codekit, it fails on things like:
floor(#grid-gutter-width / 2);
I'm guessing Less has changed but after searching, I can't figure how it's changed. Pages I've been combing through:
https://bootstrapdocs.com/v3.0.2/docs/getting-started/
https://github.com/twbs/bootstrap/releases?after=v3.1.0
https://github.com/less/less.js/blob/master/CHANGELOG.md
QUESTIONS
In general, what's the best way of handling this without breaking everything?
Does anyone know which Less changes are causing the compile errors?
Is there a version of Bootstrap 3 that works with newer Less versions?
Or would I have to somehow run an older version of Less inside Codekit?
Any pointers in the right direction would be much appreciated.
The issue was a change in Less 1.4.0 Beta 1 & 2 (2013-03-07)
maths is now only done inside brackets. This means font: statements, media queries and the calc function can use a simpler format without being escaped. Disable this with --strict-maths-off in lessc and strictMaths:false in JavaScript.
You can use the --strict-maths-off flag but I decided to plug in Bootstrap v3.3.7 and update the theme to support the newer Bootstrap (and less).
Related
as shown below:
I don't understand why, the syntax and format is correct, it's extremely confusing.
I review my code carefully but can't figure out
this seems to be a bug with VS Code. This could be because VS Code is not updated, or an extension that is not supported anymore.
first, try ctrl + shift + p and running >Developer: Reload Window this should reload your current environment and the error should be fixed.
If that doesn't work, try a different extension. I currently use Vetur, and Prettier.
And don't forget to make sure your VS Code is up to date. go to the bottom left and click the settings cog, then check for update or updates.
My answer is, "Start from scratch, and record your steps." I'm happy to share my notes on what is presently working: https://github.com/TheAutomaTom/VsCodeSettings-Vue3
My personal machine had been in that spot for some weeks, so I took a step back and dump out your cornucopia of extensions and their dependencies.
Only run pertinent language services. This is a tall order given how much a Vue + Typescript + Tailwind on Vite app covers. I am suspicious of generalized HTML/CSS/JS packs though, because they may not be built to parse Vue SFCs. Every new release of a services intended for other frameworks, like Angular or React, are still possible culprits (and moving targets).
I gave up getting Prettier and ESLint on stable ground. For a non-workplace thing, I feel okay about that. You may be having issues with a global package, if you've been experimenting. I've tossed out a couple branches following different tutorials. I intend to revisit this one since it has some example projects: rvest.vs-code-prettier-eslint
I've noticed the Volar team seems to let oddities squeak out a little more frequently than I remember in Vetur.... but we love them just the way they are. Sometimes I downgrade just to check if I've gone crazy, yet.
A lot of angular related projects use a pre-release versioning scheme of the following:
e.g. angular-cli
1.0.0-beta.22,
1.0.0-beta.22-1,
1.0.0-beta.24
e.g. #angular/material
2.0.0-alpha.9
2.0.0-alpha.9-1,
2.0.0-alpha.9-2,
2.0.0-alpha.9-3,
2.0.0-alpha.10,
2.0.0-alpha.2.0.0-alpha.11,
2.0.0-alpha.11-1,
Due to the way semantic versioning works (dot separators, numeric always lower precedence to alphanumeric parts), 2.0.0-alpha.9-experimental-pizza is still the highest version for #angular/material, even tough 2.0.0-alpha.11 is released.
Similar for angular-cli, where 1.0.0-beta.22-1 is still the highest version, even though 1.0.0-beta.24 is released.
This causes package.json dependencies with ^ versions, e.g.
"angular-cli" : "^1.0.0-beta.22-1"
to not upgrade to 1.0.0-beta.24, because 24 is a numeric version and therefore smaller than 22-1.
I also posted this as an issue to the #angular/material issue tracker here but got no response.
Is this just an oversight, or am I missing something?
Update:
angular-cli now has versions
angular-cli#1.0.0-beta.25
angular-cli#1.0.0-beta.25.1
angular-cli#1.0.0-beta.25.2
angular-cli#1.0.0-beta.25.3
etc.
So it seems this was an oversight.
Short answer is that these are manual processes. The team hasn't invested in automating them yet. At least that's speaking for the Angular CLI, since I'm a contributor to the repository source code (but not a team member).
In pretty much all recent releases, something happened at the release, so they had to issue another version. Hence things like 1.0.0-beta.xx, has been quickly followed by 1.0.0-beta.xx-1.
Some tests are hard to run before publishing the packages. Especially for the CLI which publishes a range of packages not just one (a couple webpack plugins that the CLI uses are available as separate packages for other non-CLI seed projects to use).
Usually when the team is happy with a version, they explicitly tag it as latest, which is something npm allows publishers to do, so, you shouldn't in theory have this Angular Material alpha 9 vs alpha 11 problem, unless alpha 11 is not tagged as latest or something.
Long time later, I think it was an oversight in the alpha / betas. This is now resolved and angular projects follow semver also for the pre-release tags.
Can I specify a LESS compiler version, that is required to compile the file? E.g. in a comment at the beginning of the file:
// use 1.5.0
I've searched the docs, but it seems like there are no such option.
Basically no, there's no such option. And even if it's added in future LESS versions, an older versions still won't have it so this does not help too much soon. Besides older less.js versions, there're a few LESS ports which are also a bit behind the official implementation so you never know what happens with your LESS sources when you give it away.
(Not mentioning that each LESS compiler also usually has several options that affect CSS output, e.g.: --strict-math).
Well, there's possibility to put a sort of version guard into your code, for example once I tried something like this:
.version-guard__() when not(length(-) = 1) {
-:##-;#-:': requires LESS version 1.5.0 or higher';
} .version-guard__();
But it works in less.js only, and it's not so easy to craft an universal trick that will work with other LESS implementations since each one handles errors in slightly different ways (though, to be honest, I did not bother with that too much since my main goal was to get a reasonable error message).
P.S. Alternative version guard method:
.version-guard__ {
-+: requires LESS version 1.5.0 or higher;
}
This one works in less.js and lessphp (at least) but generates dummy CSS output (unlike the first one).
It looks like I can use:
//getbootstrap.com/dist/css/bootstrap.css
//getbootstrap.com/dist/js/bootstrap.js
to automatically use the latest version of bootstrap.
Does anybody ever do that?
You have CDN's that have a similar functionality (BootstrapCDN for example), but I wouldn't recommend to automatically get the latest version. If the new version breaks something you wouldn't know it until it's too late.
Besides, what would the benefit be? Anything major is very likely to break something, and anything minor is, well, minor.
At http://getbootstrap.com/, they say
"Downloads are pulled directly from the latest committed code on
GitHub, and as a result our docs may at times be out of sync."
Your page will load faster if you get your bootstrap from their site but it may be outdated.
Hope it helped!
I'm very keen to update a number of our servers to PHP 5.3. This would be in readiness for Zend Framework 2 and also for the apparent performance updates. Unfortunately, i have large amounts of legacy code on these servers which in time will be fixed, but cannot all be fixed before the migration. I'm considering updating but disabling the deprecated function error on all but a few development sites where i can begin to work through updating old code.
error_reporting(E_ALL ^ E_DEPRECATED);
Is there any fundamental reason why this would be a bad idea?
Well, you could forget that you set the flag and wonder why your application breaks in a next PHP update. It can be very frustrating to debug an application without proper error reporting. That's one reason I can think of.
However, if you do it, document it somewhere. It can save you a couple of hours before you remember setting the flag at all.
If you haven't already you should read the migration guide with particular focus on Backward Incompatible Changes and Removed Extensions.
You have bigger issues than deprecation. Ignoring E_DEPRECATED will not suffice. Because of the incompatible changes there will also be other type of errors or, maybe, even worse, unexpected behaviors.
Here's a simple example:
<?php
function goto($line){
echo $line;
}
goto(7);
?>
This code will work fine and output 7 in PHP 5.2.x but will give you a parse error in PHP 5.3.x.
What you need to do is take each item in that guide and check your code and update where needed. To make this faster you could ignore the deprecated functionality in a first phase and just disable error reporting for E_DEPRECATED, but you can't assume that you will only get some harmless warnings when porting to another major PHP branch.
Also don't forget about your hack and fix the deprecated issues as soon as possible.
Regards,
Alin
Note: I tried to answer the question from a practical point of view, so please don't tell me that ignoring warnings is bad. I know that, but I also know that time is not an infinite resource.
I presume you have some kind of test server? If not, you really should set one up and test your code in PHP 5.3. If your code is thoroughly Unit Tested, testing it will take seconds, and fixing it will be fairly quick too, as the unit tests will tell you exactly where to look. If not, then consider making Unit Testing it all a priority before the next release, and in the meantime go through it all, first with E_DEPRECATED warnings disabled and fix anything which comes up, then with it re-enabled once you have time. You could also run a global find-and-replace for easier to fix errors.