So we want to start a new project having a monorepo with every component as a separate project.
i.e.
App (repo)
-- Button (project)
-- -- package.json
-- Radiobutton (project)
-- -- package.json
tailwind.config.js
What we'd want to do is having a single tailwind config and be able to have a build per component run through the main package.json in App. So that we minimize the css classes left in Button for instance.
Basically a css class should be generated for Button containing only the classes used there.
Similarly it would happen for RadioButton having everything completely separate.
Has anyone got an idea of an approach to this?
I can find info on monorepo's but not in combination with tailwind specific covering multiple projects given that we don't want to have a config file in each project.
Output would then be:
dist/App
-- Button
-- -- Button.jsx
-- -- Button.css
-- Radiobutton
-- -- Radiobutton.jsx
-- -- Radiobutton.css
Related
I'm currently building a minimalist app following this CMake architecture:
-root
--QmlModule
---Component1.qml
---Component2.qml
--App1
---main.cpp
---main.qml
--App2
---main.cpp
---main.qml
I use "qt6_add_qml_module" to create a QML module at "QmlModule" level as a STATIC library.
qt_add_library(myComponentTarget STATIC)
qt6_add_qml_module(myComponentTarget
URI QmlModule
VERSION 1.0
QML_FILES
Component1.qml
Component2.qml
RESOURCES
logo.png)
Then, at App1 (and App2) level, a link to the module is done using "target_link_libraries". "qt6_add_qml_module" does some work behind the scenes in order to expose the module trough an automatically generated plugin named "your_component_URIplugin". More details about this here.
add_executable(App1Exe
main.cpp)
qt6_add_qml_module(App1Exe
URI App1
VERSION 1.0
QML_FILES
main.qml)
target_link_libraries(App1Exe
PRIVATE
myComponentURIplugin)
At Root level, I overload QML_IMPORT_PATH in order to link to the build folder and add all subdirectories.
set(QML_IMPORT_PATH ${CMAKE_CURRENT_SOURCE_DIR}/qmlModule)
add_subdirectory(QmlModule)
add_subdirectory(App1)
add_subdirectory(App2)
I run CMake without any errors, and open App1/main.qml file.
On my import QmlModule, the module can't be found:
module "lupinComponentsplugin" is not installed
How to make my module visible from my Apps ?
What step am I missing ?
I'm currently doing something similar.
I have created a demo app where I import modules. The modules provide QML and C++ items to the main app. Check the comments in the CMAKE files to find out how this works.
Here is the link:
https://gitlab.com/basic53/DemoApp
Feel free to comment on this.
Another tip: If qt_add_qml_module is not working properly, sometimes it is necessary to remove the whole build folder and update the QML code model. You can check the generated files to see, if your plugin has been created with all its types.
CMake itself was fine, this was a runtime error and not a link error.
This issue was raised because the QQmlApplicationEngine wasn't finding path towards my module's QMLDIR.
In the end, the only thing missing was an additional import path ":/" in QQmlEngine:
QQmlApplicationEngine engine;
engine.addImportPath(":/");
As shown below, Threre are two directories that are exclusively included in the build depending on the build option. (by setting CMake)
ROOT
-- src
-- moduleA
-- codeA.c
-- moduleB
-- codeB.c
commonCode.c
funcSameNameDifferentImpl function exist in both codeA.c and codeB.c. It is used in commonCode.c
In this case, how I exclude codeA.c from CLion source control indexing? When I try to navigate or go to definition, IDE is NOT working as I expected. Even IDE bring me to source file excluded in build with kind warning 'This file does not belong to any project...'
I found out below guide and check overriding file type as plain text is working well. But, I think it is too ugly, not elegant.
https://www.jetbrains.com/help/clion/controlling-source-library-and-exclude-directories.html
Is there a nice way to exclude files and directories from CLion indexing?
I think it's intuitive behavior for indexing to change automatically depending on the build target.
I am implementing sonarQube in one of my project.The source code is in java and all build files are written in gradle 2.3.My project is having 8 modules under same
repository and I am using the gradle wrapper while building the module.I checked in gradle wrapper for each module with module source code.while I trigger the build it checkout the gradle version(mentioned in wrapper properties file) from the artifactoryand use gradlew to build the artifact.
Below is mentioned in the wrapper properties files
Tue Mar 17 10:20:49 EDT 2015
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=http\://xyx.n.tson.com\:9000/artifactory/ext-release-local/org/gradle/gradle/2.3/gradle-2.3-bin.zip
while it checkout it creates a wrapper/dist in workspace in below manner(Using Jenkins)
wrapper/dists/gradle-2.3-bin/7gkccujig8oqm5bun82efob8m7/gradle-2.3/init.d/
Now I want to implement the sonar and for that I need to create global sonar.properties file or better add a section for sonarRunner Gradle task (containing all the sonar.xx.xx properties) where I can keep all the configuration and use it globally . I don't want to write the properties for each module.Can someone tell me if I am using the gradle wrapper where I can keep this property file and make it global for all modules instead of changing or creating the property file for each module.
I would put this file somewhere near your rootproject instead of having it with the wrapper itself. I would put it under $rootproject/gradle/sonar/sonar.properties)
from your build script you can reference this file via
rootproject.file("gradle/sonar/sonar.properties")
cheers,
René
If what you want is a non intrusive way to activate sonarqube plugin on your project (ie without doing a modification of build.gradle) then I have no idea of how to do that.
But if you want a way to pass properties configured in global Jenkins configuration (like server URL and credentials) to your build, then you should follow this ticket as this is a known limitation:
http://jira.sonarsource.com/browse/SONARJNKNS-217
I've cloned the OpenLayers 3 repo and merged the latest from master. There exists a recently merged pull request that I'm interested in exploring, but I'm not sure how to create a regular old comprehensive, non-minified build.
Does anyone know how to create a non-minified, kitchen sink (everything included) build for OpenLayers?
(similar to ol-debug.js).
You can use the ol-debug.json config to concatenate all sources for the library without any minification.
node tasks/build.js config/ol-debug.json ol-debug.js
Where the ol-debug.json looks like this:
{
"exports": ["*"],
"umd": true
}
The build.js task generates builds of the library given a JSON config files. The custom build tutorial describes how this can be used to create minified profiles of the library. For a debug build, you can simply omit the compile member of the build config. This is described in the task readme:
If the compile object is not provided, the build task will generate a "debug" build of the library without any variable naming or other minification. This is suitable for development or debugging purposes, but should not be used in production.
So I am running into an issue when I go to build my projects using tfs build controller using the Output location "AsConfigred" it will not detect my unit tests. Let me give a little info on my setup.
TFS 2013 Update 2, Default Process Template
Here is a few screenshots that can hopefully help fill in what I can't in typing. I am copying my build out to a file share on our network so that we can use other utilities use the output. I don't want to use "PerProject" or "SingleFolder" because they mess up the file structure we have configured (These both will run the tests). So i have the files copy to folder names "SingleOutputFolder" which is a child of the DropLocation. I would like to be able to run from the drop folder or run from the bin folder for each of my tests (I don't care which). However it doesn't seem to detect/run ANY of the tests. Any help would be greatly appreciated. Please let me know if you need any additional information.
I have tried using ***test*.dll, Install\SingleFolderOutput**.test.dll, and $(TF_BUILD_DROPLOCATION)\Install\SingleFolderOutput*test*.dll
But I am not sure what variables are available and understand where the scope of its execution is.
Given that you're using Build Output location set to AsConfigured you have to change the default values of the Test sources spec setting to allow build to find the test libraries in the bin folders. Here's an example.
If the full path to the unit test libraries is:
E:\Builds\7\<TFS Team Project>\<Build Definition>\src\<Unit Test Project>\bin\Release\*test*.dll
use
..\src\*UnitTest*\bin\*\*test*.dll;
This question was asked on MSDN forums here.
MSDN Forums Suggested Workaround
The suggested workaround in the accepted answer (as of 8 a.m. on June 20) is to specify the full path to the test projects' binary folders: For example:
C:\Builds\{agentId}\{teamProjectName}\{buildDefinitionName}\src\{solutionName}\{testProjectName}\bin*\Debug\*test*.dll*
which really should have been shown as
{agentWorkingFolder}\src\{relativePathToTestProjectBinariesFolder}\*test*.dll
However this approach is very brittle, for the following reasons:
Any new test projects you add to the solution will not be executed until you add them to the build definition's list of test sources:
It will break under any of the following circumstances:
the build definition is renamed
the working folder in build agent properties is modified
you have multiple build agents, and a different agent than the one you specified in {id} runs the build
Improved Workaround
My workaround mitigates the issues listed in #2 (can't do anything about #1).
In the path specified above, replace the initial part:
{agentWorkingFolder}
with
..
so you have
..\src\{relativePathToTestProjectBinariesFolder}\*test*.dll
This works because the internal working directory is apparently the \binaries\ folder that is a sibling of the \src\ folder. Navigating up to the parent folder (whatever it is named, we don't care) and back in to \src\ before specifying the path to the test projects binaries does the trick.
Note: If you have multiple test projects, you add additional entries, separated with semicolons:
..\src\{relativePathToTestProjectONEBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTWOBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTHREEBinariesFolder}\*test*.dll;
What I ended up doing was adding a post build event to copy all of the test.dll into the staging location folder in the specific build that is basically equivalent to where it would go on a SingleFolder build and do that on each test project.
if "$(TeamBuildOutDir)" == "" (
echo "Building Interactively not in TFS"
) else (
echo "Building in TFS"
xcopy "$(TargetDir)*.*" "$(TeamBuildBinaries)\" /Y /E /S
)
MSBUILD parameter in the build def that told it to basically drop in the folder that TFS looks for them.
/p:TeamBuildBinaries="$(TF_BUILD_BINARIESDIRECTORY)"
Kept the default Test assembly file specification:
**\*test*.dll
View this link for the information on the variable that I used and what relative path it exists at.
Another solution is to do the reverse.
Leave all of the files in the root so that all of the built in functionality works. There is more than just test execution in there. What about static code analysis, impact analysis..among others. You would have to do something custom for them all.
Instead use a pre-drop powershell script to create your Install arrangement from the root files.
If it is an application then you can use the _ApplicationFolder Nuget package to create an _PublishApplications folder same as you get for web applications.