I’m starting with Particle Workbench and I want to import an existing project but all I can get from the VS Code is an error message: Failed to import project and the source is: Workbench Core (Extension).
When I check the logs messages this is the output:
I rename the file like you suggest and the project was able to be imported succesfully! That file was created because I cloned a repo with that file too, looks like for future usage, we should ignore the lib folder created to make easier for developers to reproduce easily a selected repository.
And yes I also verified that I was logged with my particle account.
@kenco Great advise. I too observed the same “import project” error as @fabocode. In addition to temporarily renaming the existing LIB folder of the project being imported, I also had to temporally delete the library file reference in the project.properties folder of the project being imported. Now Workbench is able to import and compile the imported code.
upon importing, we try to install the libraries referenced in your project.properties file locally but as you've observed bail out if ./lib already exists. this is to ensure we don't stomp on any of your files.
looks like for future usage, we should ignore the lib folder
here's a previous discussion w/ some pointers:
we should probably auto-generate a boilerplate .gitignore file or at least call it out in the docs - sorry about that
In addition to temporarily renaming the existing LIB folder of the project being imported, I also had to temporally delete the library file reference in the project.properties
why? did you just want to avoid installing those libs locally? without them local compilation will fail (but cloud compilation will succeed assuming you replaced the lines in project.properties or were not actually using those libs in your code).
After recently reading multiple reports of that, I think that this might be a “new” task
what behavior would you all prefer? prompt to "replace ./lib?" if it's detected during an import? more helpful error messaging? other?
I'd think hanging that up on ./lib is to broad. Each and every library in that directory has (usually) got its own subdirectory and there is no risk in overwriting files that only exist in one of the two (source vs. target). So a merge should be possible.
Additionally when a conflict is detected a dialog to select which to take (source/target) would be good.