 //test/integration:redirect_integration_test is (very) flakey

This is failing pretty regularly - testing it locally and its a real deal flake - sometimes passes, sometimes not
In CI its failing fairly often and causing PRs to fail (eg https://github.com/envoyproxy/envoy/pull/25488#issuecomment-1428730776)
The error as posted on above comment is:
test/integration/redirect_integration_test.cc:704
Expected equality of these values:
1
test_server_->counter("cluster.cluster_0.upstream_internal_redirect_succeeded_total") ->value()
Which is: 0

I believe this started with #23648 (after reverting i didnt trigger) cc @pksohn (if not it began at ~same time, apologies)

I'll take a look to see if #23648 is related, thanks.


merge from arlac77/npm-package-template-esm-only

.travis.yml

chore(travis): (jobs.include)
chore(travis): add 13.2.0 remove 13.1.0 (jobs.include.node_js)
chore(travis): (script)

:tada: This PR is included in version 4.0.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Format numbers on /placetypes

For example postalcode 3686661 should be postalcode 3,686,661

https://github.com/whosonfirst/go-whosonfirst-spelunker-httpd/releases/tag/v0.0.4


[ENH] grid and random tuning

The package should include a grid and random tuning utility that can make use of predict_proba and probabilistic metrics already refactored.
This should hopefully be a minor adaptation exercise using the abstractions in sktime.

Closed by #37


seqfold not finding folding at certain sequence lengths

Hello,
Thank you for making and maintaining this tool.
I'm trying to figure out the best folding for a sequence of unknown length, so I'm trying all reasonable sequence lengths 2-100 nt
the issue is that for certain lengths, seqfold is unable to find more than a single paired base, even though there are plenty of hairpins in the sequence.
in the attached image, each line is the dotbrackt view of one seqfold run, each with +1nt of the same sequence

do you know what this software behaviour could be caused by?
Best
Tue

Hey @tuspjo, do you mind sharing the final sequence? Would help to experiment with myself.
This might happen because the "winning" structures include both the reward from the binding of basepairs and the penalization from the creation of hairpins. Ie this isn't exactly what's happening:

seqfold is unable to find more than a single paired base, even though there are plenty of hairpins in the sequence.

It's finding those structures that include one or multiple hairpins but penalizing those hairpins (and the structures that include those hairpins) in a way that the basepair binding before the hairpins doesn't overcome the penalty from the hairpins themselves.
You should be able to inspect this manually using something like below:
from seqfold import dg_cache

# `dg_cache` returns a 2D array where each (i,j) combination returns the MFE from i to j inclusive
cache = dg_cache("GGGAGGTCGTTACATCTGGGTAACACCGGTACTGATCCGGTGACCTCCC")

Take the starting/ending indexes of the hairpins you expect to form. They are likely to have a negative MFE. But expanding it outwards, that MFE starts to become positive (less likely) as the dangling ends and cost of the hairpin comes into play

Follow up, what are the free energies from these two lines? If the second one has a higher (less negative) free energy, it implies that the single large hairpin was preferred to the penalty of having another basepair in the dangling end outside of the two hairpin structure. The actual penalization code for that sort of thing is here: https://github.com/Lattice-Automation/seqfold/blob/7e008d58aaaf97368ecd3e1935b6b5aab26add0d/seqfold/fold.py#L479


Added more godoc, for internal functions.

This has the further benefit of explaining the "dialer functions" and
how to add new ones, if needed.
(There are no code changes, just more comments.)

:+1:


chore: bdd-spring-1573913121 to 0.0.1

chore: Promote bdd-spring-1573913121 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Feature request: generate separate playlist per day

Currently I assume (untested) that for say a four-day festival, if I wanted four separate playlists I could achieve this by ticking one day at a time on the customize screen and going through the generation process four times. That's a reasonable amount of effort, especially if the lineup is changing frequently.
What I'm thinking is a radio button on the customize screen along the lines of "Create single playlist" / "Create playlist per day" at the bottom of the Playlist Options section, defaulting to the current behaviour. For festivals with no separate days data the checkbox wouldn't be shown.
Having had a guess at what would need changing, I think this would be a reasonable amount of change across the pages/api/spotify/redis logic so haven't created a PR. If you approve of the idea I might consider it at some point.

I'm not too sure this adds enough value to add as a feature. Like you said, manually generating a new playlist for each day works fine. The page remembers your selections too, so it's like ~3 minutes of work to create 3 playlists for each day of the festival.
I hear you that it could get annoying if you're regenerating the playlists multiple times, but in my experience festival lineups don't really change that much leading up to it. Covid has made it a bit shakier, but for the most part I really only see one shuffle of artists a month or two before some festivals. Most of the time it's few enough artists it's probably quicker just to delete / add some songs in spotify itself.
I think I'm going to hold off on this one for now - if multiple people request it I'm happy to reconsider

You know - I hadn't actually noticed how easy this was - agreed it would overcomplicated things. Thanks for taking the time to provide feedback.

That's one of the main improvements on the todo list for this project that I've had for a while haha. I think it would be a good option to have even though it adds a bit of complication of the edge case of overwriting existing playlists that we maybe won't have permission for.


Web Map "ModelGeography-Copy" references services/layers that do not exist

Item id 87b730528f2543cb896886a974ae8876   references the following services/layers that do not exist:
https://nsec.esri.com/ags/rest/services/Hosted/ModelGeography_WFL/FeatureServer/2
https://nsec.esri.com/ags/rest/services/Hosted/ModelGeography_WFL/FeatureServer/1
https://nsec.esri.com/ags/rest/services/Hosted/ModelGeography_WFL/FeatureServer/0
Also references basemap that is not located on the NSEC server. I would expect the basemap to be a NSEC basemap if all the operational layers reside on NSEC:
https://services.arcgisonline.com/ArcGIS/rest/services/World_Topo_Map/MapServer
Also this web map references two basemap services:
https://nsec.esri.com/ags/rest/services/Basemaps/Terrain/MapServer
https://services.arcgisonline.com/ArcGIS/rest/services/World_Topo_Map/MapServer

Verified that web map was deleted. Closing issue.


Chatterbot

I keep getting an error message stating there is no module named as "spacy".
my code:
! pip install chatterbot
from chatterbot import ChatBot
Message:
~\Anaconda3\lib\site-packages\chatterbot\tagging.py in
1 import string
2 from chatterbot import languages
----> 3 import spacy
4
5
ModuleNotFoundError: No module named 'spacy'

Please see: https://github.com/gunthercox/ChatterBot/pull/1963


Improvement: Account for time already worked today in workload calculation

fn workload_per_day() does not consider the amount of time already worked today, or the time of day, so it continues to assign the same amount of time to the current day, regardless of how much of the day is left.
Consider adjusting  num_days_to_work_on to incorporate the current time-of-day when the date range overlaps today

Consider merging into #50

Consider merging into #50

This was blocked by #16


Could not validate a connection to Elasticsearch. No alive nodes found in your cluster

Hey,
Just wondering if anyone can point me in the correct direction. Running bin/magento s:up returns Could not validate a connection to Elasticsearch. No alive nodes found in your cluster
Inside the shell, curl -X GET 'http://elasticsearch:9200/' returns the following:
{   "name" : "croydex-elasticsearch",   "cluster_name" : "docker-cluster",   "cluster_uuid" : "h0TQnYTYRU-1p-IA6HgqWw",   "version" : {     "number" : "7.16.3",     "build_flavor" : "default",     "build_type" : "docker",     "build_hash" : "4e6e4eab2297e949ec994e688dad46290d018022",     "build_date" : "2022-01-06T23:43:02.825887787Z",     "build_snapshot" : false,     "lucene_version" : "8.10.1",     "minimum_wire_compatibility_version" : "6.8.0",     "minimum_index_compatibility_version" : "6.0.0-beta1"   },   "tagline" : "You Know, for Search" }
I'm a bit confused what else to try.
Cheers

Late at night and my concentration isn't the best. The url in my db was incorrect!
Issue sorted.


feat(lanelet2_extensions): add transverse mercator projector

Description
I would like to add Transverse Mercator Projection method for Autoware.

Related links
https://github.com/orgs/autowarefoundation/discussions/3582

Tests performed
Loaded a sample lanelet2 map with a custom pointcloud map which is also projected with Transverse Mercator Projection, and confirmed that pcd and lanelet appear on RViz and sample rosbag runs with logging_simulator.
Note that this feature is not implemented in Autoware Universe yet. The above procedure has been done in customized Autoware Universe that is soon to be implemented in public.

Notes for reviewers
N/A

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

@kminoda
Thank you for the PR. I made some suggestion so please check them out.
Also, please add a brief description in the README as well under Projection section:
https://github.com/autowarefoundation/autoware_common/tree/main/tmp/lanelet2_extension#projection
Something like the following might be good:
### Transverse Mercator Projector
This projector projects latitude longitude into Transverse Mercator coordinates.
This is similar to [UTM projector](https://github.com/fzi-forschungszentrum-informatik/Lanelet2/blob/master/lanelet2_projection/src/UTM.cpp) in the Lanelet2 library, but uses a custom central meridian on a given origin.

@mitsudome-r Thank you for the quick review :pray: :pray:
I updated the Readme as well.

@mitsudome-r Sorry I didn't have an approval to merge. Could you do that for me?

@mitsudome-r Sorry I didn't have an approval to merge. Could you do that for me?


removing map-crictl-dockercli page from v1.29

In context with : https://github.com/kubernetes/website/pull/42017#issuecomment-1943175458
and removing the page as decided in the discussion in https://github.com/kubernetes/website/pull/45548#discussion_r1756661622

/kind cleanup


Do not force nssm executable download and installation

Addresses #28

Closing in favor of https://github.com/dhoer/chef-nssm/pull/27


How to replicate old observeNew behavior?

Apologies in advance if this is in the wrong place or if this is answered somewhere else because I did look and could not find a concrete answer to the question (I also wasn't sure if I should maybe post this in the ReactiveKit repo instead).
I am currently working on a Swift 2>3 migration in an app that uses Bond and dealing with updating the observation calls.
observe is now observeNext and observeNew is gone. What I am trying to do is add an observer that will ignore any previous elements and only respond to new ones from the time the observer is added and I'm not seeing a way to do that. Someone else asked the question and figured out that they can use the skip function but as far as I can see that only lets you specify the first or last n elements to ignore. What I am trying to do is ignore any already existing elements and case about new ones going forward regardless of how many already exist, which as far as I can tell is what observeNew did before.

Hey, I'm not sure about older versions of Bond, but to answer your question:
.observe gives you Events, where Event is an enum defined as:
enum Event<Element, Error> where Error : Error {
    case next(Element)
    case failed(Error)
    case completed
}

So Event can either be .next(let value), .completed or .error(let error).
.observeNext gives you just the .next case's value directly, and is just a convenience method really (you can also observeCompleted, for example).
Both - in the general case - give you values from the time that you observe the signal.

Hi, thanks for the response! I actually just tested this and it is not exactly the case. To summarize, when you add an observer to a normal observable/property, by default the block will fire once immediately using the last value from the observable. As such, just doing skip(first: 1) does the trick here by ignoring just that existing value and firing for everything going forward. In any case, thanks for the help! I consider this closed now.


Makes CNI config more flexible

This just needs to be rebased on main to fix the linting issue.


feat: support dag alway autolayout

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


GQL Mesh Improvements - Summary Issue [trivago feedback]

This is an ongoing issue which is used to keep track of potential GQL Mesh improvements. The feedback comes from use cases in trivago.
Most of the issues or ideas are related to the following use case:

programmatic usage of GraphQL Mesh
combining data from several sources (GQL, MySQL, etc.)
using various schema transforms
providing authorisation layer on the final schema
integrating the final schema into an existing server

Example Repository: https://github.com/Kiesen/graphql-mesh-express
Tasks:

[x] 1) The GraphQLHandler cannot use a ready-made introspection schema. -> #2783
[ ] 2) Provide a documentation recipe for using 1 schema with 2 different sources
[ ] 3) Try using envelop instead of express-graphql. Might be useful to replace the post execution of extensions from express-graphql with some module from envelop in order for the persistChanges layer to work smoother.
[ ] 4) Try moving the full schema building process to compile time instead of runtime. Identify blockers.
[ ] 5) Provide documentation for various programmatic modules used in the repo

Hey @angelsvirkov,
happy to read a conversation about feedback and potential improvements.
Probably people watching this repo can share several thoughts on the points you have raised.
But I wonder how you'd like this conversation to progress.
Is there any specific action item you'd like GraphQL Mesh to start looking into?

Hey @angelsvirkov,
happy to read a conversation about feedback and potential improvements.
Probably people watching this repo can share several thoughts on the points you have raised.
But I wonder how you'd like this conversation to progress.
Is there any specific action item you'd like GraphQL Mesh to start looking into?

Hi @santino , I have discussed that with @Urigo and @ardatan . The main idea is that we together work on specific things to improve. I will be adding different issues for every task where we can continue a more specific discussion. Also I might continue adding points to this overall issue summary. I can try solving some of those myself or else I will ask for help

Hi! I'll be interested in your ideas on future work considering introspection (caching), but since this discussion doesn't have an acceptance criteria, it fits better there ("discussion" not "issue")?
2/ there are two strategies to combine multiple sources, and we have examples:

federation: https://github.com/Urigo/graphql-mesh/tree/master/examples/federation-example/
stitching: https://github.com/Urigo/graphql-mesh/blob/master/examples/openapi-location-weather/.meshrc.yaml

3/ before you build your own gateway you should consider SDK generation solutions too
4/ that's like it already works for SDK generation?

Hi! I'll be interested in your ideas on future work considering introspection (caching), but since this discussion doesn't have an acceptance criteria, it fits better there ("discussion" not "issue")?

@JustusNBB , I would agree that a discussion could be a better place. Should we convert it?

2/ there are two strategies to combine multiple sources, and we have examples:

What I was talking about here is having 2 GraphQL Data sources which use the same schema. Only the endpoints and the actual data content are different. We did make it work by using encapsulation and reusing the same schema for both data sources. I see this as a problem which others might also face, so I was wondering if a short recipe / documentation would be something useful. I could write that if you believe it makes sense.

3/ before you build your own gateway you should consider SDK generation solutions too

We have considered using sdk generation solutions but we decided to go our own way and using your APIs programmatically. We have this for almost a year now and we are happy with the solution as it is flexible and we could integrate it into our existing service and reuse some functionality from it.

4/ that's like it already works for SDK generation?

Yes, it works for it but we would like to do it programmatically and not via the provided mesh commands because we cannot be flexible with them.

Yeah seeing how this branches the discussion forum should be a better place imo.

2/ there are two strategies to combine multiple sources, and we have examples:

What I was talking about here is having 2 GraphQL Data sources which use the same schema. Only the endpoints and the actual data content are different. We did make it work by using encapsulation and reusing the same schema for both data sources. I see this as a problem which others might also face, so I was wondering if a short recipe / documentation would be something useful. I could write that if you believe it makes sense.

Ah now I understand better what you mean, I saw related issues too and I am still looking for a great solution myself, documentation is not rounded out for this yet since the build/runtime split imho.
Please leave a comment from your point of view: https://github.com/Urigo/graphql-mesh/discussions/2618

3/ before you build your own gateway you should consider SDK generation solutions too

We have considered using sdk generation solutions but we decided to go our own way and using your APIs programmatically. We have this for almost a year now and we are happy with the solution as it is flexible and we could integrate it into our existing service and reuse some functionality from it.

Can you explain more what you have been doing exactly?

4/ that's like it already works for SDK generation?

Yes, it works for it but we would like to do it programmatically and not via the provided mesh commands because we cannot be flexible with them.

Environment configuration does not work for you?

@JustusNBB , I think I have no rights to convert this issue to a discussion. Regarding points 3 and 4 - You can check out the example repo we have set up. It contains a small scale replica of how we use the mesh. Regarding the discussion in #2618 about Multi Mesh vs Mega Mesh I am still not quite sure what that means and how it relates. I'd think more about it.

You are using lerna, see this related nx topic: https://github.com/Urigo/graphql-mesh/issues/2103

https://github.com/Kiesen/graphql-mesh-express/blob/master/packages/backend/src/mesh/mesh.ts

That reminds me of myself half a year ago, switching from the Gateway approach to SDK generation, back then I started to programmatically composing the mesh like you do here, without a .meshrc.yml (workaround findAndParseConfig...) but I got stopped by frequent internal mesh changes, and then graphql-mesh was refactored and split into build & runtime with introspection cache - I currently have more that one .meshrc.yml file for smaller (validation-only) use cases, while trying to get TypeScript (ts-node) dependencies removed from the built artifacts, maybe not related - just fyi.
@santino @ardatan can you recommend the code-only approach (without .meshrc.yml) or is it more preferable to rely on one or more .meshrc.yml files in general and for specific use cases?

Sorry for late response. I'd recommend to keep using CLI if possible. We recently did a few improvements by removing ts-node dependency etc.

Try using envelop instead of express-graphql. Might be useful to replace the post execution of extensions from express-graphql with some module from envelop in order for the persistChanges layer to work smoother.
We're currently working on Envelop/Yoga integration of Mesh. I'd recommend to check https://www.graphql-mesh.com/docs/recipes/custom-server Custom Server feature to provide your own server that uses Envelop in favor of Mesh's.

Try moving the full schema building process to compile time instead of runtime. Identify blockers.
We are gradually moving schema generation process from runtime to compile time. It also needs some work on Schema Stitching side.

Provide a documentation recipe for using 1 schema with 2 different sources
Are you referring to dynamic endpoint URLs while using the same introspection?

The GraphQLHandler cannot use a ready-made introspection schema.
I created a PR on your repo that seems to fix the issue you had.

Hi @angelsvirkov!
Thank you for your complete feedback!
Please know that we took notes of your suggestions when rewriting the GraphQL Mesh documentation: https://www.graphql-mesh.com/docs/introduction
We now provide more advanced examples/tutorials (single sources, multiple sources, sources with no definition):

programmatic usage of GraphQL Mesh: https://www.graphql-mesh.com/docs/guides/extending-unified-schema
combining data from several sources (GQL, MySQL, etc.): https://www.graphql-mesh.com/docs/getting-started/combine-multiple-sources
using various schema transforms:  https://www.graphql-mesh.com/docs/getting-started/combine-multiple-sources
providing authorisation layer on the final schema: https://www.graphql-mesh.com/docs/getting-started/customize-mesh-server
integrating the final schema into an existing server: https://www.graphql-mesh.com/docs/getting-started/customize-mesh-server

Let us know if you have any feedback on the improved documentation 👀


[SPARK-24102][ML][MLLIB] ML Evaluators should use weight column - added weight column for regression evaluator

What changes were proposed in this pull request?
The evaluators BinaryClassificationEvaluator, RegressionEvaluator, and MulticlassClassificationEvaluator and the corresponding metrics classes BinaryClassificationMetrics, RegressionMetrics and MulticlassMetrics should use sample weight data.
I've closed the PR: https://github.com/apache/spark/pull/16557
as recommended in favor of creating three pull requests, one for each of the evaluators (binary/regression/multiclass) to make it easier to review/update.
The updates to the regression metrics were based on (and updated with new changes based on comments):
https://issues.apache.org/jira/browse/SPARK-11520
("RegressionMetrics should support instance weights")
but the pull request was closed as the changes were never checked in.
How was this patch tested?
I added tests to the metrics class.

Test build #73528 has started for PR 17085 at commit 48800eb.

Test build #73528 has finished for PR 17085 at commit 48800eb.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/73528/
Test PASSed.

@sethah @Lewuathe @thunterdb @WeichenXu123 @jkbradley @actuaryzhang @srowen would you be able to take a look? I've split the larger pull request into three parts as suggested.

ping @sethah @Lewuathe @thunterdb @WeichenXu123 @jkbradley @actuaryzhang @srowen could you please take a look?  thank you!

Test build #89406 has started for PR 17085 at commit d5acd46.

Test build #89406 has finished for PR 17085 at commit d5acd46.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/89406/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/2352/
Test PASSed.

Jenkins retest this please

Test build #89414 has started for PR 17085 at commit 17c1626.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/2358/
Test PASSed.

Test build #89414 has finished for PR 17085 at commit 17c1626.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/89414/
Test PASSed.

Merged build finished. Test PASSed.

Test build #99946 has started for PR 17085 at commit aca6255.

Test build #99947 has started for PR 17085 at commit 0de3209.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/5951/
Test PASSed.

Test build #99948 has started for PR 17085 at commit 0480721.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/5952/
Test PASSed.

Test build #99947 has finished for PR 17085 at commit 0de3209.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test build #99948 has finished for PR 17085 at commit 0480721.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/99948/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/5956/
Test PASSed.

Test build #99952 has started for PR 17085 at commit 0cb2daf.

Test build #99946 has finished for PR 17085 at commit aca6255.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Test build #99952 has finished for PR 17085 at commit 0cb2daf.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/99952/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/99946/
Test FAILed.

@srowen yes, exactly, there is a third PR here for classification: https://github.com/apache/spark/pull/17084
But I need to update it in a similar way to how I just updated this PR (eg 2.2.0 -> 3.0.0).

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/5981/
Test PASSed.

Test build #99982 has started for PR 17085 at commit f708edb.

Test build #99982 has finished for PR 17085 at commit f708edb.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/99982/
Test FAILed.

Test build #99984 has started for PR 17085 at commit 24b66da.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/5983/
Test PASSed.

Test build #99984 has finished for PR 17085 at commit 24b66da.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/99984/
Test PASSed.

Merged to master


Fix url typo in Inference API docs

https://huggingface.co/docs/inference/endpoints => https://huggingface.co/docs/inference-endpoints/index

Thanks :pray:


firefox-bin: 52.0.2 -> 53.0, firefox-esr: 52.0.2esr -> 52.1.0esr [Critical security fixes]

Motivation for this change

Critical security fixes
Two new 'compact' themes available in Firefox, dark and light, based on the Firefox Developer Edition theme
Lightweight themes are now applied in private browsing windows
Reader Mode now displays estimated reading time for the page
Updated the design of site permission requests to make them harder to miss and easier to understand
New visual design for audio and video controls
Ended Firefox Linux support for processors older than Pentium 4 and AMD Opteron
Support for WebM video with alpha, which allows playing videos with transparent backgrounds

https://www.mozilla.org/en-US/firefox/53.0/releasenotes/
https://www.mozilla.org/en-US/firefox/52.1.0/releasenotes/
https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/
Tested (playing a YouTube video) both firefox-bin and firefox-esr. firefox-esr may not work with old profiles made with older firefox-bin, but it works with a fresh profile.
I could not build firefox (source package) yet. It now requires Rust and Cargo, but adding cargo and rustc (or rust) to nativeBuildInputs does not work.
[edit] I edited a wrong file. Now configure succeeds and compiling. [/edit]
[edit] I got /tmp/nix-build-firefox-unwrapped-53.0.drv-0/firefox-53.0/extensions/spellcheck/hunspell/glue/mozHunspell.cpp:203:34: error: 'class Hunspell' has no member named 'get_dict_encoding'. Maybe hunspell need to be updated. [/edit]
Things done

[X] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[X] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Fits CONTRIBUTING.md.

I got error /tmp/nix-build-firefox-unwrapped-53.0.drv-0/firefox-53.0/extensions/spellcheck/hunspell/glue/mozHunspell.cpp:203:34: error: 'class Hunspell' has no member named 'get_dict_encoding' while building firefox. Maybe hunspell need to be updated.

Ported to 17.03, too, after a bit of testing.  Thank you!


skip creation of routes

I usually only use routes in core, because having routes in multiple modules may lead to re-renderings (see https://github.com/mantrajs/mantra-core/issues/9),
so it would be cool to just be able to disable route generation in other modules than core (maybe via setting)

That's fair. Do you have plans for how to implement it?

hmm...

[ ] config createRoutesOnModules: true/false
[ ] do not create route file when createRoutesOnModules is false (if its not core module, i think we should always create it)
[ ] verfiy that the module index file does not import the route file when createRoutesOnModules is false

that makes sense. Feel free to open a PR and I will review it before we release.

This would also help with React-router as routes for rr are only in core.


[ffmpeg] Update to 4.1.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: peters sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Related: https://github.com/Microsoft/vcpkg/pull/3578

It looks like there is the same aubio and pangolin breaks.  I am testing the aubio fix from @alexkaratarakis and will look into the pangolin issue.

building pangolin with --head still has the LNK2001 issue reported earlier.  It also has a C2719 error.  I don't plan on digging into this further at this time.

Pulled fixes for pangolin into a patch to address some of the build failures.  I am retesting the PR now.

There was still a build break in static aubio on windows that I addressed.  Running tests to verify that is the last issue.  If they are good I will be able to complete this merge.


Bug with multiple missing "}" in raw_llm_output, and with some new line chars

Local LLMs sometimes give invalid json. In my case they often just forgot to close it with "}". Current solution only adds one "}" at the end to fix that. It also throws an error sometimes when raw output has new lines (or other chars), but not standard \n  - I did't identify it yet.
To Reproduce
Steps to reproduce the behavior:

Start with local llm (text-gen) (e.g. dolphin-2.1-mistral-7b.Q6_K.gguf)
Ask few times about long emails or json examples
Usually After 3-20 tries V
See error Failed to parse JSON from local LLM response - error: Failed to decode JSON from LLM output

Quick fix:

Replace in clean_json  line with extract_first... to data = extract_first_json(raw_llm_output)
Replace string with raw_llm_output in function call: extract_first_json(raw_llm_output)
Add inside extract_first_json just before print("No valid JSON object found.") this:
if depth != 0:
for j in range(depth):
raw_llm_output = raw_llm_output + "}"
return json.loads(raw_llm_output)

That anyway is just a temporary fix, that works most of the time for me, parsing json from raw output should be done in a bit more proper way. Adding just more "}" at the end is not a great solution. We should not only force llms to push proper json (maybe even add agent that will only work on parsing json) but even if the output is not valid json that should be hard coded into a correct form.

The problem with new lines occur when there is just '\n' in params part of raw_llm_output. Again quick fix would be to just remove all '\n'. A bit better way - find just inside of value of params and replace only there those '\n' with '\n  ' or '\n'

I run some test and by the looks of it this repo https://github.com/mangiucugna/json_repair does the job quite ok. I did not get an error since I added that. It can also just replace json.loads() with json_repair.loads()

Looks like memgpt is not able to return any json since last night. I came up with few solutions but to solve it there should be some standard for functions and validation based on schema.


Typo fixes in comments

Correct spelling of words in source code comments.

:+1:

Current coverage is 52.89%

Merging #1451 into master will decrease coverage by -4.06% as of aa80478

@@            master   #1451   diff @@
======================================
  Files          123     123
  Stmts        11438   11438
  Branches       805     731    -74
  Methods          0       0
======================================
- Hit           6515    6050   -465
+ Partial        805     731    -74
- Missed        4118    4657   +539

Review entire Coverage Diff as of aa80478

Uncovered Suggestions

+0.28% via ...ge/driver/gcs/gcs.go#182...213
+0.24% via ...rage/driver/s3/s3.go#168...195
+0.24% via ...rage/driver/s3/s3.go#115...142
See 7 more...

Powered by Codecov. Updated on successful CI builds.

LGTM


Evaluate current Localization accuracy of current NDT scan matching against Localization dataset

We should compare the localization performance of Autoware before/after Autoware Labs activity.
Once we create a pointcloud map for the data collected in this issue, we should do evaluation of current Autoware's localization accuracy.
For the accuracy, we can try using RTK output as ground truth.

There is no guarantee that RTK is always accurate so I appreciate for any other way of getting ground truth data.

I tested with data which is this PR shared.
Here is the localization broken points in here on the google earth.
You can open this .kml file on google earth.
Also you can see broken points on pointcloud map in here
You can open this file with Cloud Compare.
I will also share test video.

I made some parametric changes and also we collected new data because of time problem in last data. You can check out the some test results with new data.
1.) To start, I simply wanted to observe how autoware localization works.  Test Video
I did this test with Default autoware. Since I don't have the vehicle velocity as a Twist source, I did this test using the TwistWithCovarianceStamped message from GNSS/INS.
There are 2 tunnels on our route. As expected, localization was disrupted while passing through the tunnels. Apart from this, no visible disruption was observed in localization at first glance.
2.) The error of GNSS/INS in the tunnel increases as seen in the video above.However, the frequency of the Twist message does not decrease or the Twist message is not interrupted. For this reason, I wanted to check if using the speed coming from here causes an error in the tunnel. For this reason, I tested the localization in the tunnel by giving only NDT poses as input to EKF. In this test, no Twist message was given to EKF. Test Video

I added Show&Tell Discussion for explaining to tests --> https://github.com/orgs/autowarefoundation/discussions/5135

Added document to Autoware Documentation . We can close this issue .


Document how to use book mutliple cores for a single task

This is to clarify one of the outcome of #181.
Several people have asked how they can use dask-jobqueue to submit multi-threaded tasks. There are two answers currently:

we can use resource_spec or specific scheduler equivalent kwarg to book more cores than nprocs*nthreads started with dask-worker.
or we can use resources functionnality, which allows to submit both multi-threaded or single threaded tasks on the same cluster.

This needs to be documented.
@lesteve made up some examples: see https://github.com/dask/dask-jobqueue/issues/181#issuecomment-449341161.

Would this also apply to computing dask arrays (client.compute)? For example, if I have a dask array that is the result of many array operations that perform best on a threaded scheduler by themselves, is there an easy way to say that this array and all of its pre-tasks should be computed on a single worker? It's possible the scheduler is smart enough to keep the data on the same node anyway.

@djhoese you can specify a worker name from client.compute (http://distributed.dask.org/en/latest/api.html#distributed.Client.compute), but I'm not sure resources can be used as a kwarg. Feel free to ask a question in distributed tracker or on Stack Overflow.

As per the OP, the resources kwarg solution, seems to have some issue yet. See #230 or https://github.com/dask/distributed/issues/1851.
You cannot use adapt() or scale after tasks submission.


add: Initial repo setup

Date: 4/11/2024

Developer Name: @MehulKChaudhari

Description
This PR will add basic repo setup for frontend of feature-flag, (React Typescript Vite)
Documentation Updated?

[x] Yes
[ ] No

Under Feature Flag

[ ] Yes
[x] No

Database Changes

[ ] Yes
[x] No

Breaking Changes

[ ] Yes
[x] No

Development Tested?

[x] Yes
[ ] No

Note: Tests setup will come in subsequent PR, It would have increased the number of files changes and the scope of this PR that's why keeping it separate.


$webPush->sendNotification returns true but not sending

NOTE: Please test in a least two browsers (i.e. Chrome and Firefox). This
helps with diagnosing problems quicker.

Please confirm the following:

[ x] I have read the README entirely
[ x] I have verified in the issues that my problem hasn't already been resolved

Setup

Please provide the following details, the more info you can provide the
better.

Operating System: <Linux | Windows | OS X>
PHP Version: <5.6 | 7.0 | ...>
web-push-php Version: <1.0.0>

Please check that you have installed and enabled these PHP extensions :

[ x] gmp
[ x] mbstring
[ x] curl
[ x] openssl

Please select any browsers that you are experiencing problems with:

[x ] Chrome
[x] Firefox
[ ] Firefox for Mobile
[ ] Opera for Android
[ ] Samsung Internet Browser
[ ] Other

Please specify the versions (i.e. Chrome Beta, Firefox Beta etc).

Problem

Please explain what behaviour you are seeing.

Send returns true but works only with Firefox. With chrome nothing happens. All examples say ..android.. for the address but it seems it has changed to fcm.googleapis.com... I assume something has changed there.

Please explain what you expected to happen

Features Used

[ x] VAPID Support
[ ] GCM API Key
[ x] Sending with Payload

Example / Reproduce Case

Please provide a code sample that reproduces the issue. If there is a
repository that reproduces the issue please put the link here.

Other

Please put any remaining notes here.

Is this still being developed?

Hello, if it returns true, it is successfully sent. It appears that the notification is not received properly on your end though. Please make sure you're using correct client data and code. See examples


The css animation attribute acts on the root dom of the vue file, and cannot be successfully switched when switching routes

Version
4.1.5
Reproduction link
codepen.io
Steps to reproduce

vue template has   router-view> transition>keep-alive
when a vue file root dom with animation attribute
vue router don't work

What is expected?
vue router should work
What is actually happening?
vue router don't work

Your repro is importing the node vue router version, it's normal it doesn't run.

Remember to use the forum or the Discord chat to ask questions!


Wizard: should be able to hide close ("x") button

Select one ...  (check one with "x")
[ ] bug
[x] feature request
[ ] enhancement

Expected behavior

There should be a way to hide the close ("x") button on top-right of a wizard. This is especially an issue when there's an alert showed on top.
Actual behavior

There is no way to hide the close ("x") button on top-right of a wizard
Reproduction of behavior

Any Clarity wizard can reproduce this.
Environment details

Angular version: 2.1.1

Clarity version: 0.6.0

OS and version: OS X El Captain 10.11.6

Browser: [ Electron ]

@yaooluu do you want to hide/show only when the error is there or are you looking for a way to not include the "X" at all?
On another note, could you provide more details as to why you're showing the error on top of the title in the Wizard. What is the use case where you need a page-wide error vs. inline errors to where the issues are with the possibility of having an error icon on the name of the page in the left-side TOC?

Hi @jaffoneh, the use case here is that the error banner shows errors that are returned from backend after use submitted the form by clicking "Next" on wizard page. This is a convention we've followed in a product series.
I'm looking for a way not to include the "X" at all. Like the option we have for Modal clrModalClosable.

cc @youdz to provide an opinion here.

@jaffoneh, @yaooluu: No, [clrModalClosable] will not work right now because the wizard currently wraps the modal and doesn't offer a delegate for it.
Yes, this is a valid request that we should address. It's as simple as offering a delegate [clrWizardClosable] on the wizard component that just passes it to the modal through [clrModalClosable].

Thanks, @youdz. @adityarb88 could you take a look and see what we can do there?

@jaffoneh: Sure. I will add this to my list


Register package

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/87332
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" 1ece6d094031d9be74eef8aa5415d51abb059d7d
git push origin v0.1.0


Add a button to refresh the list of authored apps

Closed by https://github.com/flathub/website/pull/1089


[Services 2] Prepare Pods for Relay

Prepares Pods for relay integration.

@MatApple I've rebased the branch for you and changed the base branch to master

This seems to work well! I pushed a small style change but otherwise I think it's good to go. :ship:

@orlandohohmeier thanks for rebasing this for me! Lets get this in and I'll address your comments in the coming week. I'll be changing the way modals are handled and I'd like to chat about that some more.


RP2350 support

RP2040 successor : https://dmitry.gr/?r=06. Thoughts&proj=11. RP2350

2x Cortex-M33F
improved DMA
more and improved PIO
external PSRAM support
variants with internal flash (2MB) and 80 pins (!)
512KiB ram (double)
some RISC-V cores? Low power maybe?

That's really interesting!
I haven't looked much into any of the new Cortex M33 chips since all the CMSIS stuff is Apache 2 licensed.
I wonder if anyone has clean-room made their own. Seems like an enormous task.
Too bad there wasn't a Pi Pico with a Cortex M4 and tons of RAM. Would be excellent.
I could do what a lot of other projects do and just git submodule the CMSIS and HAL stuff, but I would like the OS to be as self-contained as possible.
I'll keep thinking about this..

Oh, and new release is on the 11th. Get any bug fixes in asap.


Related: Repo and Organization

#v5 Issue templates are missing on v6 branch. Also, organization link must change with the new domain.

It will be added shortly, as well it's been known.


Adding an option to use replaceState() method instead of pushState()

The excellent plugin uses pushState() in order to change the URL on every tab press, creating a deep link to the tab. This, however, causes every tab change to be added to navigation history.
This PR adds an option to use replaceState() method instead, so the URL is changed, but the history is not written, allowing the back button to go to the previous page.
This fixes #20.

This would be really helpful for my use case as well; any chance of this getting merged? Thanks!

Actually, this PR didn't quite work for me as-is, so I adapted it here: https://github.com/demiankatz/Geeby-Deeby/blob/57247f5acfc118ea6c0e742055e9149a0b7b30a0/public/js/vendor/jquery.stickytabs.js


Release resourcemanager/security/armsecurity v0.1.0

[ ] The purpose of this PR is explained in this or a referenced issue.
[ ] The PR does not update generated files.

These files are managed by the codegen framework at Azure/autorest.go.

[ ] Tests are included and/or updated for code changes.
[ ] Updates to CHANGELOG.md are included.
[ ] MIT license headers are included in each file.

/azp run prepare-pipelines

/azp run go - armsecurity - ci

/azp run prepare-pipelines

/azp run prepare-pipelines


$24000 STOLEN FROM Classicetherwallet.com   I want it returned!

Transaction Details
Timestamp
Jun 29, 2017 6:56 PM
Value
1327.9796 ether
1327979559000000000000 Wei
$23,903.63
Hash
0xb8d3b6ee453b0d4841b53532e69677da0868b17474ee237abdf10d4c06e684ad
NOnce
0
From
0x4c6c1e80e06550e7b5f58e19c012ec8a09dd67c5
To
0x2b8cc0d2901a04145c86c7ae22ca649f974f0e34
Block Height
4004410
Block Hash
0xca586dd3b6c9ed0d684919ad301307f98a87cc81dffdfb7a3336fe323bde3c6c
Gas Provided
21000
Gas Used
21000
Gas Price
21000 Mwei

Hi, I'm in your own condition do you think someone will refund us ???? what do we do if none of the support responds ??

Pretty sure there is no way for them to refund anything. we all just lost. I think the best they can do is figure out how it happened.

It happened because we used a corrupt Russian shyster website that was a
scam. I'm getting all my coins off of every online wallet service. I don't
trust any of these parasitic Shyster! Did you see the guy who claims to be
the owner of classicetherwallet? He looks like he was hatched in a swamp.
His name is Igor Artamonov. He's probably the culprit. Dirtbag
On Jun 30, 2017 12:32 PM, "smokeyta"<EMAIL_ADDRESS>wrote:
Pretty sure there is no way for them to refund anything. we all just lost.
I think the best they can do is figure out how it happened.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ethereumproject/etherwallet/issues/54#issuecomment-312354927,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARiGmQAJBwHwEuAVzomNfjBVbRY-vEtOks5sJU1ngaJpZM4OKM8k
.

hi, my ether classic also stolen : http://gastracker.io/addr/0x1174C30E1B14842F482666d7AaD3d9E476B69215
Block: 4002608
Confirmations: 6975
29 Jun 2017, 06:55
From my adres: 0x1174c30e1b14842f482666d7aad3d9e476b69215
TX Hash: 0xbcd93931
43.0866 ether
all gone to this adres: 0xce52bfaf3f4900fecfbf43b8da2890cf59cab323
from that adres all transfered to this adres: 0x6c73962cbfda97ac8867499f1116b7e1b5d310d7
Is there any way to get it back ? i don't get it... is it really so unsafe this ether classic ???????????
Everything my machines did for one month is gone.... i really hope someone can get it back for me...
Please send it to this adres if possible: 0xa931c2ebcbc6dde30ad93efc57c639e67871c6d4
total : 43.0866 ether
I really hope to get it again.... 43 ether is maybe not much for someone but it is very much for me...
Thanx in advance
best regards
Miki

We have to do something guys ... so I'm not there

hardfork? :rofl:

https://github.com/ethereumproject/etherwallet/issues/62


Fix class names for elements

Expected Behavior
Two or more words in class names should be concatenated without dashes.
Actual Behavior
Some elements are named like "links-list" or "scroll-icon".
Specifications

Package version: 0.2.32
OS: All
Browser version: All

P.S.: Muilessium should migrate to the standard rscss methodology.


Optional Sass Support

Note from Maintainers
We now have official Sass integration documentation.

Would be nice to include CSS compilers such as: Sass, Less, Stylus, or even CSS modules, etc.

I'm not sure we want to make anything optional, in the sense of having people choose between multiple options. Anectodal evidence, we went down that route for generator-keystone and it's really hard to maintain.
What you have in create-react-app at the moment is a solid, unopinionated base to just get started™. If people want to add more advanced features they can always eject! (or choose a boilerplate 😉)

I see where you’re coming from but I’d like to learn more about your use case for Less / SASS in React. With components and a BEM-like convention, many their features are actually not that useful.
The only one I can think of that I’m truly missing in this setup is the ability to share constants across files. This is useful e.g. for color themes. But there is an escape hatch even for this: you can use JavaScript styles (or just inline styles) and then import those values.
What other features are you missing?

No Testing?
No LESS or Sass support
No Hot reloading of components

So how is this project useful if you still have to add these things to ease your development?

Perhaps just adding recipes or documentation for various customizations, like Sass or test runners, using the eject is simple enough and does not require making the project opinionated.
This would help beginners (like me) be able to step their way to something more complicated.

So how is this project useful if you still have to add these things to ease your development?

We’re sorry if it’s not useful to you yet. We think that many people learning React would appreciate even the current feature set.
Please let’s keep this issue focused on Less/SASS, not on other issues. You can discuss testing in #80. Hot reloading of components won’t be supported until I figure out how to make it more stable (I’m the author of React Hot Loader). I fully intend to work on this, but there are more pressing issues.
Thanks!

@appjitsu This project isn't made for you then—it's just the basics to get started with a basic web app for demos and learning the basics of React. This isn't ember-cli for React.
There's plenty of awesome projects in that vein like @mxstbr's boilerplate. The simplicity of this project is the best part about it.

Sorry. Don't take my comments as being rude. I think this is a fantastic project.
Although, I do view each of those features to be critical for ease of development.

On Jul 22, 2016, at 12:50 PM, Dan Abramov<EMAIL_ADDRESS>wrote:
So how is this project useful if you still have to add these things to ease your development?
We’re sorry if it’s not useful to you yet. We think that many people learning React would appreciate even the current feature set.
Please let’s keep this issue focused on Less/SASS, not on other issues. You can discuss testing in #80. Hot reloading of components won’t be supported until I figure out how to make it more stable (I’m the author of React Hot Loader). I fully intend to work on this, but there are more pressing issues.
Thanks!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Well OK then! Thanks! 😄

On Jul 22, 2016, at 12:53 PM, Juan Soto<EMAIL_ADDRESS>wrote:
@appjitsu This project isn't made for you then—it's just the basics to get started with a basic web app for demos and learning the basics of React. This isn't ember-cli for React.
There's plenty of awesome projects in that vein like @mxstbr's boilerplate. The simplicity of this project is the best part about it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@appjitsu  Didn't mean to sound like I thought you were rude, sorry 😄
Those features are definitely awesome for development and production, but this is for learning and demos (for now at least). Give it some time.

^^ good discussion but let’s focus on Less/SASS in the future comments 😉

SASS would be awesome to have available. I absolutely would have used it today for a project had SASS been available.

My issue is that if you allow Sass, you'll get "where's PostCSS/Sylus!?!?!?!". It's a can of worms you have to open carefully.

@thecodegoddess What features of SASS do you use most often that you miss in regular CSS?

@gaearon It's more that is what our current architecture is using. I know that you can get away with PostCSS for much as well. Mostly, we have variables and mixins that we are currently using.

It would be great to have option from the cli when you first create the project. Similar to yeoman generators.

On Jul 22, 2016, at 1:11 PM, Juan Soto<EMAIL_ADDRESS>wrote:
My issue is that if you allow Sass, you'll get "where's PostCSS/Sylus!?!?!?!". It's a can of worms you have to open carefully.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Sure, adding a flag (--sass) is easy but again, what will Facebook do when Stylus/Less/PostCSS people complain? Supporting all CSS preprocessors isn't fun and having the user config their own kinda defeats the purpose of a no config project (and technically the flag is configuration!).

@thecodegoddess
This makes sense, thanks. For now we want to focus on making this useful for new projects because there are all sorts of conventions in old codebases that would be tricky to support. But I agree we need some solution for variables (postcss or otherwise).

Supporting all CSS preprocessors isn't fun and having the user config their own kinda defeats the purpose of a no config project (and technically the flag is configuration!).

Not adding flags or configuration options is a hard constraint of this project in the coming months. We might revisit this later.

I know people in the SASS / LESS camps might not be too supportive of this, but here goes.
This project currently uses Babel to ensure that all ES2015 and ES2016 features are supported. So, were ensuring that we the latest JS standards even though the browser support may not be there. So why not take the same approach with CSS and add officially add support for css-next?

I thought about css-next but there’s a lot of stuff there. The direction seems valid though.
The most conservative thing we could do is add support just for variables. But obvious we’d need imports too.
Whatever we add, it needs to be rock-stable. I’m worried about issue lists like this: https://github.com/postcss/postcss-import/issues.

We want to wait and see, and most of all we want to understand what problems people are solving with Less/SASS in new React apps today. Perhaps there are other, easier solutions.

I understand your concerns, but in my case sass it's a default. It's not about solving a particular problem, It's just part of my workflow. Just to be clear, maybe the purpose of this tool is not to address every case, but it looks so clean and cool that it saddens me I have to eject and pollute the whole app just to get sass support. I'll be following the development of this tool either way because I think it's great. Thanks.

Got it, thanks for your perspective. We understand people might be used different tools, but we can’t implement support for them just because of that, as we wouldn’t have good rationales for why some tools are supported and some are not. Then we have 10 different supported tools, and we aren’t sure if they all work, and we need to do a lot of extra work if some underlying tech (like bundler) changes.
I hope this gives you some perspective on why we’d rather avoid adding anything that can be solved by existing means.

http://developer.telerik.com/featured/why-bootstrap-4-means-sass-has-won

There is a project called React Bootstrap, does it use either? cc @taion
We shouldn't just do something because Bootstrap does it. Components change how you think about modularising UI quite a lot. So constraints in which Bootstap is operating are not the same as constraints you meet developing React apps.
You should be able to use Bootstrap in React projects, sure. This doesn't mean that something that "won" for Bootstrap is necessary for a React project.
PS I would like further messages in this thread to focus solely on features of Less/SASS that you feel components + CSS don't solve well. Let's not just argue "what is better" because it doesn't help us to make any decisions. Thanks.

Obviously. And it would be pointless to list the benefits of one or another here. That is well documented all over the internets. My point was that if you were to choose one preprocessor, SASS is the clear "winner", because of adoption. If facebook doesn't want to choose, then let us choose.

React-Bootstrap just provides React components. We don't ship any of the styling. In cases where I use React-Bootstrap, I pull in Bootstrap via npm, and use less-loader in my webpack config. In general, users of React-Bootstrap will need to provide the Bootstrap CSS somehow, but we don't care how.
But if you want to talk more broadly about Less, Sass, or cssnext, my feedback would be:

In practice, Sass makes more sense than Less; Sass seems to have effectively "won"
Sass is much more user-friendly than cssnext
The cssnext variables syntax is verbose to the point of being painful
Your app doesn't have to be very big at all before mixins are very useful (e.g. style variants for buttons), and they're not in cssnext
If you use CSS modules, then you will hit https://github.com/webpack/extract-text-webpack-plugin/pull/166, and anyway the way you do composition and components with CSS modules is actually radically different from how you normally do CSS
You can pull together a bunch of PostCSS plugins to make something Sass-like, and @jonathantneal's PreCSS actually gives you that, but then effectively you're shipping something like Sass, except less popular and less familiar to users

Given all that, my recommendation would be to bundle Sass support. I don't think the PostCSS-based ecosystem is sufficiently mature to offer a good option in the context of a project aimed at developers who want an easy way to get started.

Ah, got it, thanks for clarifying.

And I'd be totally fine with pointing users of React-Bootstrap at bootstrap-sass instead of the Less version if they're trying to use React-Bootstrap with create-react-app.

@taion Exactly.

@taion  Good arguments.
@gaearon  Would it help if some of the people here wanting this support offered to maintain this particular feature?

Personally, I prefer Sass, I'd be open to anything that allows math and variables in stylesheets.   I'm pretty new to React, so maybe there's a more standard React-way to do these things with and perhaps some links in the README is all that's needed.

What do you use math for? Layout, color tweaks, something else?

CSS calc is already supported in every browser that React supports, though, no?
But writing e.g.
border-radius: calc(var(--height) * 2)

feels awful compared to writing
border-radius: calc($height * 2)

@gaearon I use math mostly for layout and color. Though, I usually use Sass functions for color math.
@taion Agreed.

@taion to play devil's advocate here: it doesn't matter if it feels awful, that's what people are going to use in a few months/years time! It's a standard, whereas Sass is just Sass.
Including CSSNext is like including Babel, including Sass is a custom thing that not everybody knows.

This project feels a bit confused.
If the goal is to make it as easy, and less configuration as possible to get into the ecosystem. Including Sass support makes sense, because it is highly used already and entirely optional. It doesn't harm anyone, and anyone who wants to remove it to optimise their build process is going to eject anyway.
If its to create a 'best practice' project, then it should be what fits in best with the react ecosystem and 'react-way'. Which is my opinion is CSSNext (React - It's just JS / CSSNext - It's just CSS) but is really for the React community/team to decide.
There just isn't any real projects out there that would use straight CSS unless they are doing it for some weird optimisation/capability reasons. You are therefore forcing anyone doing something than 'trying it out' or following a tutorial eject.

cc @jquense who I'm sure has opinions on this
@mxstbr
It's true that cssnext is "special" in that sense, but I think unlike e.g. ES2015/ESNext v CoffeeScript, cssnext is meaningfully worse to use than Sass. For example, we deliberately switched away from the cssnext variable syntax toward the Sass-style one, because the cssnext variable syntax is awful, and assuming you'll be running some sort of build step on your CSS, it'd be a bad choice to go out and use it.
I wish someone told me before I started building stuff with cssnext that, actually, the cssnext syntax stuff is just way, way worse than Sass, and that I should have just used either Sass or PreCSS instead.

And the cssnext color function spec is, like... I understand why it is that way, and it is that way for a good reason, but:

It's bad DX for color(red lighten(+10%)) and color(red lighten(+ 10%)) to do dramatically different things (and you almost always want the latter)
But DX aside, you'd always prefer to evaluate the above at build time rather than at runtime anyway, whenever possible

BTW: http://cssnext.io/it-s-cssnext-not-CSSNext/
I think cssnext is a great, well-intentioned project, just as Babel is. The problem isn't cssnext; the problem is that, for reasons that I think are somewhat distinctive to styling, most of the upcoming spec functionality implemented by cssnext is much worse than that in Sass-like frameworks.
I can't see why anybody with a build pipeline would want to write var(--button-height) rather than $button-height, or choosing a color modifier syntax where if you accidentally write color(var(--my-color) lightness(+10%)), you end up setting the lightness to 10% rather than increasing it by 10%.
</rant>

To pigback on @taion's point, the big reason cssnext isn't worth its is it's features are intentionally (in most cases) not actually polyfillable. The value-add of many these new features is that they offer something that a preprocesser cannot, which is awesome, except that it most neuters the usefulness of something like cssnext. What you get instead is something with the same potential abilities (things that can be polyfilled) as SASS but with a DX and syntax and such that is far inferior to SASS/LESS.
That added with the fact that it doesn't really even future-proof you, because its not to spec in some cases, and for a bunch of features you would never actually write them the polyfilled version (like custom properties). Not to make sweeping generalizations but I don't thin things like SASS are not going away any time soon

CSS variables are already supported by all browsers except IE and Edge according to this chart:
http://caniuse.com/#feat=css-variables
To me, it seems silly to use sass variables, if most browser support other variable systems natively.
At this moment, I'm making an chrome extension, so actually, in my project I can use css variables today together with react-scripts. And they work fine. Okay, the syntax is not that pretty, but Webstorm (other editors probably as well) provide good autocompletion and lints.
You can also edit the variables in your chrome dev tools. I'm not seeing your problem @taion Is it just syntax?

@kasperpeulen thats really poor browser support for anyone who is making an app that needs to support windows or mobile users :P.

@jquense Yes, sure, perfect for a chrome extension though. What I mean, 2 years ago, things like coffeescript and sass totally made sense. But now that ES6 is supported by most browsers, and CSS variables are supported by most browsers, I think it makes less sense to use a different syntax for css variables than the official supported syntax by (future) browsers, and use postcss so that also windows users are supported.

One difference is that CSS isn't a programming language. Most of the "advanced" features – variables, color functions, calc, &c. – can be evaluated statically, so no matter what, normatively you want to have a build step.
Again, assuming you have a build step (e.g. because you're using CSS modules), why would you let the browser do the color math instead of doing it at build time? And if you're not going to have the browser do it, why would you choose to use a syntax where lightness(+10%) does something awful?

@jquense while custom properties are not transpileable they are still usable to implement simple variables – I agree that SASS variables alone are easier to use and I'd be fine with them (one can always refactor them with postcss/codemod).
However the point is which features and APIs to use: SASS is monolithic and opinionated, PostCSS is modular and can bring on standard features.
As I see it SASS is the CoffeeScript of CSS-land, it introduced lots of awesome features and concepts and possibly influenced the standards development but at this point is not necessary anymore :)

@giuseppeg
Certainly, and in fact we use a custom Sass-like pipeline that runs through PostCSS. If I were to build a new project from scratch, I'd probably start with PreCSS instead of Sass.
The issue is that the goal of this project is to create zero-configuration scaffolding for React applications. As such, "you can deeply customize what you do in PostCSS" is not just irrelevant but actively contrary to the intent here.
Like, it's directly contrary to the idea of being able to easily set up a real React web project if part of this is "now go choose between these dozens of modular PostCSS transforms". This project adds value by not making users make choices.

and even moreso if its more intended for new users, the PostCSS ecosystem is on the edge, which is really cool, but not great for folks if you need good documentation or help. Whereas the SASS ecosystem is big, well established, and  easily google-able.

Like, if you think about why this project is so great – Babel 6 is hugely modular and configurable and everything, so power users can do exactly what they want... but relative to the less modular Babel 5, that customizability is friction for new users.
The modularity and customizability of Babel 6 is fantastic from a technical point of view, but in the context of project scaffolding, it's a bad thing – in fact exactly the kind of bad thing that projects like "create-react-app" help to work around.

@taion agreed but
This project adds value by not making users make choices.
I don't want to be forced to use SASS (just to mention one), also considering that the tool is for scaffolding a new project – I'll quote you – "you'd probably start with something else instead of Sass".
dozens of modular PostCSS transforms
The pro-PostCSS movement is asking for a few basic plugins, namely: custom properties, imports, calc, custom media queries. One can always hook SASS up later I guess.

I don't want to be forced to use SASS

I mean by using a tool with opinions ppl are going to by defination have to use stuff they might not choose, thats the cost of not having to choose. Given that the thing that these projects should optimize for is "best for most" and "not actively exposing more choices" to which we are arguing that postCSS is not a great choice, its not a Critism of PostCSS its just noting that it's actively trying to provide very different value than this project :P

Most of the "advanced" features – variables, color functions, calc, &c. – can be evaluated statically, so no matter what, normatively you want to have a build step.

Slight aside: Custom properties in CSS cannot be evaluated statically because they can be changed in-browser and everything that uses them will update, contrary to Sass variables.

I know they can't strictly be evaluated statically, but they'll most often be used in a way where they could be – just with worse syntax than the Sass equivalent.
And moreover, again, our experience with PostCSS was – we started with postcss-css-variables, but ended up with postcss-simple-vars because the latter was just better.
So why give users something (1) worse, (2) harder to use, and (3) effectively just an arbitrary choice anyway?

Just a suggestion. create-react-app is already auto reloading the CSS when index.css changes.
You can add a sass folder and an easy gulp script that watch the sass folder and rebuild the code. For example:
var gulp          = require('gulp');
var sass          = require('gulp-sass');
var sourcemaps    = require('gulp-sourcemaps');

gulp.task('serve', function() {
    return gulp.watch(["./sass/**/*.{scss,sass}", "./bower_components/styles/sass/**/*.{scss,sass}"], ['sass']); //Add here your lib folders
});

gulp.task('sass', function() {
  return gulp.src("./sass/**/*.{scss,sass}")
    .pipe(sourcemaps.init())
    .pipe(sass({
      indentedSyntax: true,
      includePaths: ['./bower_components/styles/sass'], // Add here your libs
      errLogToConsole: true
    }).on('error', sass.logError))
    .pipe(sourcemaps.write())
    .pipe(gulp.dest('./src'));
});

gulp.task('default', ['sass', 'serve']);

That is what we use at our company.
We started with a boilerplate that used https://github.com/webpack/extract-text-webpack-plugin and https://github.com/jtangelder/sass-loader . It did not take too long with our javascript code, suzy, bourbon and our styles before it was taking 60+ secs to recompile everything and see the updates when you were saving a line in SASS!
After we switched to gulp for CSS, it takes less than 2 secs and we decoupled the JS and the CSS compilation process.

Personally, I'd like to see this project remain un-opinionated about CSS pre-processing.
Components + CSS are highly capable. They're easily capable enough for the infant stages of a project.
Can we compile a list of Sass use-cases, relevant to the scope of project like ceate-react-app? I'd be surprised if most couldn't be solved with component-based thinking.

Another use-case that still haven't mentioned: nested selectors. I often write in my SCSS:
.component {
   /* styles for component */
   &:hover {
       /* styles for hovered component */
   }
}

It looks pretty neat and you don't need to type main class name several times.
This is the main reason, alongside the variables, why I add preprocessor in every my new project.

Sass support here wouldn't force users to use Sass – it would just allow them to use Sass without extra work.
Per:

We expect that at early stages, many people will “eject” for one reason or another, but as we learn from them, we will make the default setup more and more compelling while still providing no configuration.

"Just plain CSS" with no preprocessing or postprocessing is not a good way to build anything nontrivial.
The blog posts suggests that this project is intended as more than just scaffolding. Right now, any user that wants to do anything non-trivial with styling is forced to eject. Presumably that's not desirable.

Presumably that's not desirable.

Absolutely correct! Which is why it's good to have this discussion about what we're going to include. :blush:
I haven't really seen a good reason to include Sass yet. (except "It's popular", which isn't what this project is looking for)
I'd much rather go with a component-based styling model since that is what I think the entire web community will converge around one way or another. (doesn't matter if it's react or another framework, the component idea is here to stay)
I don't particularly care if that's CSS Modules, JSS, Aphrodite, jsxstyle or whatever you want as long as it fits the mental model of react. Sass doesn't do that, it's "just" popular syntactic sugar.

It seems like you can add Sass support pretty easily with a solution like https://github.com/facebookincubator/create-react-app/issues/78#issuecomment-234739359 . That seems pretty nice because you aren't changing anything about how create-react-app behaves - you're just adding an extra gulp task to convert your sass into css. It's not quite as nice as using a webpack loader directly, but if you want that you can still eject. Since it's not that hard to use Sass in conjunction with create-react-app, I don't think we need to add extra support.

@mxstbr
It's not just a matter of popularity/stability, though. If you look at the Babel config here, it very sensibly excludes things like stage-0 and only uses a subset of stage-1. My argument against including something like PreCSS or CSS modules isn't that those are bad ideas in a vacuum – it's that they're both too bleeding edge to be something we should implicitly recommend to novice users.
@lacker
The gulp task sort of works, but it's really ugly, and it exposes users to race conditions, especially when making a production build. In practice that advice pretty much becomes "eject and add a Sass loader".
Contra

PS I would like further messages in this thread to focus solely on features of Less/SASS that you feel components + CSS don't solve well. Let's not just argue "what is better" because it doesn't help us to make any decisions. Thanks.

above, I don't think it makes sense to frame this discussion in the context of features. It's not just about the features – it's about any number of things like stability, ease of learning, popularity, &c.
That's, like, why we write JS instead of Dart, say.

My argument against including something like PreCSS or CSS modules isn't that those are bad ideas in a vacuum – it's that they're both too bleeding edge to be something we should implicitly recommend to novice users.

Fair enough if you think that way, but then let's not include anything at all since Sass isn't helping?

@taion i disagree with the idea that CSS pre-processing is required for a "non-trivial" applications. thinking about architecting styles around components is just different but no less capable. Our large applications haven't written any new Sass after adopting React.

@chantastic My experience is very much to the contrary. We're doing a from-scratch build, and if anything, we've pulled in more PostCSS transforms as time has gone on, rather than fewer – going from cssnext to essentially a discount Sass.
@mxstbr Could you elaborate on the problems you mentioned upthread in including both Sass and Less support in generator-keystone? Naively that seems like it'd just be the easiest way to go.

The more opinionated this tool becomes about non-React workflows, the less useful it is as a starting point for React beginners.

I agree that saying "you must use Sass" would not be good.
A strawman: ship support for Sass, maybe Less, and add a few of the most useful PostCSS transforms.
This is very unopinionated – people who like Sass can use Sass... people who don't can just go ahead and not use Sass.
Hence my question to @mxstbr.

create-react-app: an un-opinionated starter-kit for CSS pre-processing exploration.

"Unopinionated" means the user makes the choice, not the framework.
Saying "you should use raw CSS" or "you should use the following blessed set of PostCSS transforms" is just as opinionated as saying "you should use Sass".

Again, this is an impossible discussion to have without defining how far the pre-eject setup should take you.
It seems unfriendly to eject and have a package.json littered with dependencies I don't want, need, or have any relevance to building the React app.

To answer the generator-keystone question:
The big problem is that it creates a lot, and I mean a big lot of overhead for the maintainers. Everytime the tiniest thing changes you have to test it in multiple variations and creations. Even with the best intents and testing everything bugs slip through every second time. (things like this)
You also end up maintaining things you don't use yourself, which is the worst-case scenario for an OSS project imo. You'll get unmotivated to fix some LESS problem because you're using Sass and "Who's not using Sass anyway?" and then you never prioritize and get it done.
I would highly recommend avoiding the scenario of the user being able to choose. (as well as that being an explicit goal of this project)

What's the most common way devs in the React community are handling component styling? Is there a best practice or "React way?" Is the issue that the React community itself is split?

Sure, so that's really the crux of the problem.

If you don't bundle some CSS pre-processing or post-processing, then users are incapable of following standard best practices for styling their web apps.
If you only bundle one framework, then you are making an opinionated choice
If you bundle multiple frameworks, then you have extra maintenance burden, and end up with extra stuff post-eject

@geekydatamonkey
If I had to guess, Sass with BEM is the most common baseline approach. See e.g. https://github.com/airbnb/css.
Experienced/advanced developers doing greenfield projects often choose CSS modules with PostCSS, or one of the CSS-in-JS approaches like Aphrodite. This is what we do. I absolutely would not recommend this as a general approach – it's full of sharp edges that will leave cuts, and broadly requires a different way of thinking about styling, because CSS cascades largely no longer work as a tool.
One can argue, and indeed I have argued, that CSS cascading is not a "good" way to write styling rules, but these arguments are abstract, and should not be taken as normative for what generally accepted best practices are.

Right. I think we disagree on the first, which makes not adding any new dependencies the clear winner (to me).
What's wrong with create-react-app followed by an immediate npm run eject?

Because then this package is just a very elaborate custom-built Yeoman generator.
Again, not shipping any additional CSS processing is not somehow "unopinionated". "Just use CSS" is very much an opinion, and it's not the opinion that the majority of the internet takes.
Remember that we, the participants in this discussion, are not the target audience. I'm glad you're comfortable using CSS + components. On my side, I'm quite happy with CSS modules.
That's entirely different from saying that these are reasonable as prescriptions for how people should build React apps – they're not.

My opinion is formed by how confusing large dependency trees are to beginners. If this is something that is going to be marketed toward beginners, describing why the project depends on ALL css pre-processors but doesn't required them, is unfriendly.

None of the build dependencies are visible to users pre-eject:
$ npm ls --depth 0
<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>

Right. It's just magic, until you eject, at which point you have no idea what your code depends on. Now I have to know what packages to remove post-eject. That doesn't help newcomers learn in a progressive way.

Yes, that's the natural tension for this sort of project.
The more you do pre-eject, the less the post-eject configuration is going to be tailored to your specific needs.
However, the less you do pre-eject, the more likely users will have to eject in the first place.
In general, "just use plain CSS" is not a particularly great recommendation for how to handle styling. Moreover to the point, though, it's also a very opinionated recommendation.

How did eject get a negative connotation. It's doing a lot for you, even when you eject immediately.
Why should I expect this library to know anything but what is required to build React?
You're attempting to twist this into a discussion about CSS being opinionated. The point is keeping the core competency of a React-focused starter on React and nothing more.

I think the distinction you're speaking to is the one between the minimum usable scaffold and the minimum useful scaffold.
Consider hot reloading via React Hot Loader, for example. Per discussion in https://github.com/facebookincubator/create-react-app/issues/93, it looks like the intention is to add it to this library. I think that's a good choice, because RHL is very useful.
What it isn't, though – it's not in any form a requirement to use React. If I were scaffolding a minimal React application by hand, I would not use React Hot Loader. If I eject, React Hot Loader is an extra dependency that your hypothetical user would have to find out about.

RHL is one package that—in fact—is related to React. You're talking about adding Sass/Less/Stylus/PostCSS/etc all for the benefit of being un-opnionated. It's sprawling.

In any case, I find the discussion uninteresting. I'm going to eject myself from it.

Now that CONTRIBUTING.md states "If the community is split between different tools, we won't just pick the least controversial or most popular, the tool itself should be agnostic between them." I think the current philosophy to not support any particular css preprocessor is clear, & I think this discussion has gotten distracted, so let's close this. We can always rediscuss later if something changes.

I agree with @taion on this:

Again, not shipping any additional CSS processing is not somehow "unopinionated". "Just use CSS" is very much an opinion, and it's not the opinion that the majority of the internet takes.

For me how to start with React has never be . The problem has been "what is the best starting point if I want server side rendering, SASS, hot-reloader, being able to use ES6 npm modules with npm link, great logging and keep a great development speed?".
I think who comes to react, unless they are starting web development from sketch, is looking a way to plug some of the tools they are familiar with. CSS pre-compilers are some of them.
I saw too many boilerplates. It is no easy to say this is the "best one" especially when I was new to react . I think that a repo like this backed up by Facebook has the potential to become "the" reference tool.
At the same time I think people should have an easy path to add the tools they like.
Having options is not a problem. The problem is having too many options that lack documentation and having to spend days to make the system work the way you want it.

I think I am part of the targeted audience for the creat-react-app as I started trying to learn react less than a week ago. The config part is pretty overwhelming and when I saw the announcement a couple of days ago I immediately started a new project to try yesterday.
After 20 minutes I was already wondering "Ok, how can I use sass (and pug) with this ?" so there you go, a newbie experience.
I will however add that I completely understand the desire to stay un opinionated and a lot more feedback from new users should be reviewed before taking such decisions.
I ended up ejecting just to take a look under the hood and felt a bit overwhelmed by it. Now I'm wondering if learning everything from scratch wouldn't be better since I would have a better understanding of what is going on and I could set up my project to support the tools I use most (sass/pug).
The good news is that in less than a minute I had a react project running so I can start messing with it and for that the creat-react-app is awesome and does what is advertised, the bad news is that it also feels like a sandbox where I can play but if I want to develop something I'll have to learn it all from scratch anyway.

That's excellent feedback @Lakston, thanks so much for taking the time to post that!

By the way, as we said above, we are open to learning why you find SASS useful in your projects (apart from habit). Since this issue has become a little bit too broad, perhaps it’s worth creating another one where we specifically collect SASS features that you find useful in React projects.

@gaearon
I can speak to this a bit. For the main project we're working on, we've migrated from "just plain CSS" to "CSS modules with cssnext" to "CSS modules with a heavily Sass-like scheme".
First, my experience with CSS modules leads me to recommend against either CSS modules or CSS-in-JS in this sort of context. Modularized CSS is awesome, but it works very differently from normal CSS, and has enough sharp edges that "using properly modular CSS" is very different from and not a strict requirement for "using React". They go great together, but it's definitely advanced right now.
In terms of specific features that we make use of:

CSS variables/custom properties: these are immensely useful for e.g. defining a set of theme colors and using them consistently throughout our web app. Specifically, I'd like to highlight the Sass-style $variable syntax as being much more usable than the custom properties var(--variable) syntax. I can't really explain it, but the advantage in usability of the former is much more than you'd expect.
Color functions: This links directly to the above – we define some theme colors, and want to use a consistent set of variations in brightness for things like borders, shadows, &c.
Mixins: Again this connects to the above – for things like defining a consistent set of style variations, e.g. different style variants for buttons, like if I have a confirm button that I want to be green, a delete button that I want to be red, &c., but keep a consistent relationship for use of gradients, shadows, &c.
Nested selectors: Again just a usability thing... it's way nicer to nest .child under .parent than to do .parent .child... even moreso for defining :hover, &c. pseudo-classes. Here I actually do think the cssnext syntax is nicer than the Sass syntax, but the transform has significant problems in working with invalid selectors like &-bar and & + &

BTW, I don't think the issue count on postcss-import is representative of the stability of that plugin (and more than, say, facebook/react's issue count is representative of React's usability 😛). I haven't had any bad experiences with it.
v8.x introduces some interesting complications from async processing, but they haven't caused me any problems in practice, and otherwise v7.x is rock-solid.

Though to continue on this note, the biggest problem with the PostCSS transforms isn't stability – it's that they allow spec-incompliant things that are very tempting to use.
For nesting as above, we found ourselves actively wanting to use selectors that don't work like &-bar and & + &. Currently, the plugin transforms that into something that does in fact "work", but  per the spec they shouldn't.
This comes up for the color function stuff too – right now, color(red lightness(+10%)) will increase the lightness by 10% as a user would naively expect, but per the spec this should set the lightness to 10%, and the correct form for what almost everyone would want here is actually color(red lightness(+ 10%)).

Thank you very much for the context, this was super helpful. We’ll keep this in mind, and will be referencing this issue when making decisions in the future.

Pardon the logorrhea on my part – on PostCSS, to summarize, we've found the stability just fine. The issue instead is that with the cssnext stuff, it's very easy to write CSS that is badly broken per spec but will right now get processed into something that works.
This is fine for advanced users that are willing to go the extra mile to make sure they're not writing spec-incompliant CSS that still happens to work in cssnext, but to me seems extremely dangerous for general use – like a repeat of the Babel 5 decorator thing, but worse.

First off I would love to have Sass support out of the box.  Adding a loader doesn't opt anyone into using Sass - if a Sass file exist it gets parsed.
Looking at this post from @tylermcginnis https://medium.freecodecamp.com/create-react-app-and-the-future-of-creating-react-applications-3c336f29bf1c#.qky3g94y1 very small sample but the CSS comments are both questions about using Sass.
<EMAIL_ADDRESS><EMAIL_ADDRESS>That said as for Less, Stylus others (likely Sass as well ... ) can they be supported via PostCss?
https://github.com/gilt/postcss-less
https://github.com/MoOx/postcss-cssnext
https://github.com/seaneking/poststylus
I have an issue open here tweaking the plugin setup for PostCSS that would handle these cases
https://github.com/facebookincubator/create-react-app/issues/171

We haven’t made any final decisions here. It’s just that we think this is currently out of scope, and we want to come back to this when we have time to look at CSS in React more holistically.
In the meantime you can always use a console SASS tool that outputs .css files right inline, and put *.css in .gitignore.

I think this might be a good place to consider adding some customizability.
Ultimately, the choice of CSS framework is mostly orthogonal to the tooling complexity in setting up React.
I think giving a very limited set of choices for mostly orthogonal things like the choice of CSS framework would be a value-add here.

I have to say I don't really like the idea that SASS isn't being considered "just because people use it."  I fully understand that you are trying to find out "why" people want it included before you decide  what to do.   However, I would ague that because so many people use it, is really just as valid of a reason.
If the goal of this project is to help beginners, then I would suggest most beginners out there probably have spent a lot of time in the world of SASS over the last few years on the web.  These newer concepts for CSS are great, but for most people SASS is what they know.  So by limiting these people to either new concepts or plain CSS you limit the goal of the project.
Just my thoughts.

Just to make it clear, you can use SASS with this project if you want to.
If you’re used to SASS, you’re also probably used to launching it in the console and letting its watcher compile the SASS files. So this is exactly what you can do:

Put *.css into .gitignore
Create *.sass files instead of *.css
Launch the SASS watcher and let it create the CSS file(s)
Import that *.css file(s)

Yes, this is a bit of extra work, but it’s perfectly doable.

@gaearon there is some important issue with your solution: you can't run the whole your development environment with a single npm start, you would have to run sass-watcher is a second process.
That probably will be blocker against doing this.

That probably will be blocker against doing this.

How is opening a second terminal window a blocker? 😃 It's CMD + T and then npm run sass, that doesn't seem like a blocker!

You can also change your start command to start the SASS watcher before react-scripts start.

@mxstbr let's say it like I have to open twice more terminal window than before
@gaearon if I do this:
node-sass --watch --recursive src & react-scripts start

Then I will not be able to stop node-sass because it will be in background.

There are workarounds to that too. (But it might be easier to write your own Node script that spawns both.)

@gaearon thank you, that probably solves my issue

@just-boris you can define pre and post scripts in npm that will run before/after a given script e.g. start.
FWIW you can bring up processes that are running in background with fg [ jobid ] and eventually kill them with ctrl+c

The node-sass watcher in the background with its pid in a variable for cleanup on ctrl+c is a really clean solution.
I also recommend using node-sass binary from your node_modules folder to avoid global dependency.
Another thing to keep in mind is that the --watch option prevents node-sass to compile unchanged files on startup hence the need of a compile-sass rule for initial compilation.

The only thing I will support by default is cssnext just because at the end of the day we are writing CSS.

My workaround uses node-sass and concurrently.  Install both as a dev dependency and modify your start script to ./node_modules/.bin/concurrently -r './node_modules/.bin/node-sass src -w -o src -r' 'react-scripts start' I'm surprised how well this works. If it fails to compile, the error stays in the console until the error is cleared and I found that by adding -r to concurrently it doesn't mangle the original colors.

Is there any reason flags can't be supported. For instance create react app --sass. There's no harm in having the option and it wouldn't make the project confusing for new people. Those that want sass, just add the flag. Most dev cli's have flag options for additional functionality. Why's this a problem?

This is my personal opinion so please don’t take this as an official position of React team or something like that. Here goes.
Adding any flag explodes the number of possible configuration we need to support. The day we add less-loader and sass-loader, many of these issues become our issues because they affect our users in the configuration we recommended:

https://github.com/less/less.js/issues
https://github.com/webpack/less-loader/issues
https://github.com/sass/node-sass/issues
https://github.com/jtangelder/sass-loader/issues
https://github.com/webpack/css-loader/issues?utf8=✓&q=is%3Aissue is%3Aopen modules

We take issues in the underlying libraries very seriously. We follow up with them and make sure they get fixed, fork or replace the dependencies, if necessary, so that our users have the best experience. But we are not ready to officially support the spectrum of CSS transpilation alternatives.
Unlike, for example, Babel plugins, we don’t use SASS or Less at Facebook, so we have no idea which issues are affecting the users, and would not be able to allocate enough time and effort to fix them.
Additionally SASS (the most commonly requested tool in this thread) is a wrapper over a native binary written in C/C++ which adds more rare but complex issues that we wouldn’t be able to help anyone with. If you never had any issues with these tools, it’s great. It is not cool if somebody attempts to run a React example built with an official React toolkit, and they get a segmentation fault.
At this point in time we are going to keep treating CSS transpilation as a problem outside of CRA concern. As demonstrated above you can use SASS/Less or something else in a CRA pre-ejected app if you treat .css as a compilation target that you import, and have a SASS/Less watcher running in background, just like this worked before Webpack. But we are not ready to recommend either of those solutions officially, even as we understand that many in the community use them.
Also, as I said previously, we intend to look into this space (styling in React) later this year. If our effort is unfruitful, we might give in and enable SASS/Less by default, but this will require Create React App to further mature and prove its value anyway. Let’s revisit this topic in the beginning of 2017.

We now have official Sass integration documentation.
Feel free to contribute if something is missing!
For now I think this is enough, and covers the use cases most people have.

Sass is now supported.
https://reactjs.org/blog/2018/10/01/create-react-app-v2.html


Bump Yarn workspace version

CI script is broken due to Yarn but not anymore

I was setting up the repo for contributing but was having issues due to my Yarn version being 4.4.1, why is the repo using such an old Yarn version?

@jmg-duarte no reason at all, it's been untouched for a while. Happy to approve a PR updating it