I have several simple .scss (SAAS) files and for each one I get a sass-lint error.
Unexpected Parse Error
To the best of my knowledge, I have the most current sass-lint plugin for Atom. It doesn't seem to affect anything and is more of a annoyance, however I would also love to know if I am doing something incorrectly.
Example code that generates the error:
$primaryFont: 'Lora';
$secondaryFont: 'Roboto';
$primaryHeader: 'Montserrat';
Don't worry it's not you it's sass-lint!
It is because you are indenting with spaces, there is a bug in one of sass-lint's dependencies that causes Unexpected parse error in file to be logged when you indent with tabs rather than spaces. It looks like they are planning to have it resolved in the next release, at which point the maintainer of the Atom plugin will need to update the dependencies of the Atom Package and publish a new version.
I figured this out by taking a look at the package.json for sass-lint and specifically at the dependencies on line 21, there is a direct dependency upon the sass-lint NPM package. From there you can go back to the GitHub Repository which has all of the issues including #560 which describes the exact issue you are experiencing.
I have created GitHub Issue on the sass-lint Atom Package for this, it is externally blocked by Issue #62 on sasstools/sass-lint, i.e. the NPM package, which was updated a couple of days ago by Dan Purdy who stated:
We're at a bit of a crossroads at the moment, while running through our tests on all platforms we've found the latest version of the AST fixes a lot of our issues but also breaks a few things. Specifically Sass format on windows mainly. There's also some pretty annoying windows bugs left over so we're currently debating and looking into what our best course of action is. I hope to have 1.6 out soon though... I just can't say when.
You can always try validating your .sass-lint.yml here online YAML lint tool
Related
So here is the situation:
I have a fork of go-ipfs. It depends on go-ipfs-config. I need to modify go-ipfs-config and make go-ipfs depend on my modified version.
I forked the go-ipfs-config made my changes and made sure to update the path to be that of my forked version as can be seen here. I confirmed that this still builds successfully by running go build
Then I updated go.mod in go-ipfs to use my modified version. I used the replace directive to signify this intention which can be seen here
This is where things gets absolutely bunkers and I am no longer sure what is going on.
When i do go mod tidy to fetch the dependency i get the following output:
go: finding module for package github.com/dadepo/go-ipfs-config
go: found github.com/dadepo/go-ipfs-config in github.com/dadepo/go-ipfs-config v0.5.3
The crazy thing is that v0.5.3 does not exist in github.com/dadepo/go-ipfs-config!
Also the following line get added to go.mod :
github.com/dadepo/go-ipfs-config v0.5.3 // indirect
Which can even be seen here
I have run commands like go clean -modcache and go clean -r etc but does not seem to fix things!
Does anybody know what I am doing wrong? And also how to achieve the goal of making my version of a project depend on another modified version of its dependency?
Ok, so this is as a result of me not being aware of couple of things going on in the Go lang toolchain.
Apparently https://proxy.golang.org is a thing! It is a service operated by google that caches modules. So If you made a release, deleted it, chances are that the version is already cached in https://proxy.golang.org. This was exactly what happened in my case. I had made a 0.5.3 release, deleted it, but it is not really gone as the Google cache already got a hold of it.
So in case you are seeing versions that should not exist. This should be the first place you check. This documentation link also sheds some more light on the proxy and how it can be tweaked.
I found this out based on the conversation I had on the issue I opened reporting this behaviour. If you are curious, you can check it out here.
I'm trying to go get go.etcd.io/etcd/tools/benchmark.
Previously this has worked, flawlessly. However when I try to do it currently I have alternatively got no errors and I've had it fail on me with:
go/src/go.etcd.io/etcd/vendor/google.golang.org/grpc/balancer_conn_wrappers.go:28:2: use of internal package google.golang.org/grpc/internal/buffer not allowed
go/src/go.etcd.io/etcd/vendor/google.golang.org/grpc/clientconn.go:49:2: use of internal package google.golang.org/grpc/internal/resolver/dns not allowed
go/src/go.etcd.io/etcd/vendor/google.golang.org/grpc/clientconn.go:50:2: use of internal package google.golang.org/grpc/internal/resolver/passthrough not allowed
The first time I ran it on a new go-1.13 installation it worked, but the following times it has failed as above.
The repo has not changed as far as I can tell in the past 8 months and I've tried on various golang versions but all so far have failed (bar the go-1.13 on that first try...).
Any assistance debugging this would be greatly appreciated!
I have both a workaround and an official fix.
The workaround:
Here I defined a go.mod which then used a previous version of the library.
The official fix:
This was fixed upstream and thus no one else should experience this.
I guess you can try by removing vendor folder from the go.etcd.io/etcd repo. Also disable the vendoring mode. It should work.
I've run into an issue with a chain of webpack loaders for scss files, where sometimes using single quotes for a string (legal in Sass, as I understant) causes a compile fail. I have an example that can be run, here, based on small changes from the AngularClass angular starter app:
https://github.com/karptonite/angular2-webpack-starter
You can see the relevant Webpack rule here.
This commit shows the only changes from the vanilla starter from AngularClass necessary to reproduce the bug. Instructions to reproduce the compile failure are in the README of the repo.
I'd like to report this as a bug, but I'm having trouble determining which loader to blame. possible culprits include sass-loader, resolve-url-loader, css-loader, and the ExtractTextPlugin.
I know for a fact that the error does not occur when I remove the resolve-url-loader, but it also doesn't seem to occur when I don't use the ExtractTextPlugin.
I spent hours tracking down why the build wasn't working before discovering it was the single/double quote issue; I'd like to save other people that time by reporting it to the correct repo, if I can figure out what package is at fault, but I don't know enough about how these loaders work to track it down. Can someone who understands Webpack and/or Sass take a look at this, and tell me if I've found a legitimate bug, and, if so, which loader should be fixing it?
I'm uncertain if this is an issue with Brunch or elm-brunch or some configuration detail I've screwed up. Frequently, when I change an Elm file in my project, the compilation will appear to run, but the result will show elm compiler errors that were fixed on the last save. The errors disappear if I quit and rerun the watch command. I'm not sure why this is happening or even how to narrow down the possibilities.
For setup details, I'm running it using brunch-with-elm-and-electron as boilerplate. My brunch version is 2.9.1.
Your configuration is ok. This is both brunch and elm-brunch issue. Brunch plugins are designed to compile each file separately on change. elm-brunch, however, runs elm-make for elm modules instead. That's why brunch cache is not being updated properly, causing redundant error messages.
Unfortunately, there is no quick fix, but we are looking into the problem. Here's the GitHub issue to track a progress. Thanks a lot, this is a good catch!
UPD: Here's the pull request that should fix the issue.
Good day! I became interested in the tool from Microsoft vsimporter. There was such a problem: when I try to convert .xcodeproj project .sln project in the command line the message appears "The "project" workspace does not contain any schemes". All the schemes are in place. This problem occurs randomly, because It succeded to convert two projects, but with the other two the problem above. I can not understand because of what it happens. If anyone faced with an identical problem I will be glad to any hint!
The problem you're encountering is likely due to the presence of CocoaPods – was your Xcode workspace file generated by CocoaPods? The bridge currently does not support CocoaPods because of limitations in its clang compiler front end, but it's a request we get a lot so we're investigating adding support. Try removing CocoaPods and including your third-party libraries manually. If you run into issues, feel free to get in touch by filing an issue on Github – it's the best way to talk directly to our team. Thanks for checking out the bridge!