Hey everybody, still no solution  Zakwayda is right, as much as I tested with a Blender model, I'm sure there's something wrong with my implementation. I've actually uploaded the entire engine to github. Hopefully it's not too large of a project. 

[GitHub link]

I'll leave a little guide here so nobody has to guess where everything is. By the way, if you want to run the project, you can either host the client folder or if you got node installed:

$ npm install
// after dependency download
$ node server

If you're using nodejs, the game will be served at localhost:8080.

By the way, I tried drawing the scene with no mipmapping but got the following warning: 

texture bound to texture unit 2 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.

Which is true, my planet texture is w > h. I tried it with mipmapping off, min and mag filters on nearest.

Guide

If you press the lockmouse button,  you enter fps mode enabling you to  navigate around using your mouse and arrow keys (not WASD).

CORE

1. src/engine/loop.js: Game Loop. Physics and Render loops called from here

MAIN ENTRY

1. src/main.js: This is where I create the planet entities, textures, meshes. 
   • Game.load:  calls a function in src/game/loader.js and loads all objs, images, etc.
   • Game.ready: (line26) is called once all assets are ready and before the game starts

UV SPHERE, RENDERING, MESH AND TEXTURE CONSTRUCTORS

1. src/engine/systems/drawscene.js: (line 109) Entities are rendered here.
2. src/engine/texture/texture.js: The Texture object for creating new Textures 
3. src/engine/data/model.js: (line 216) The UV Sphere function is located here, it's the very last static function.
4. src/engine/data/mesh.js: This is the Mesh object for new Meshes 

SHADER

1. src/shaders/phong.frag: The only shader I'm using aside from the post processing ones. You'll notice I'm feeding vec4 color the diffuse texture map only, ignoring my lighting algorithm for now.

MATH

1. src/engine/math: Here you'll find matrices, vectors and also a class for calculating normals.  

I took a look at the project. I think the culprit may be this in your fragment function:

vec2 uvs =  fract(uvcoords).xy * uvtile;

If you remove the fract() call, the artifacts disappear (for me anyway).

I haven't dug deep enough to tell you exactly why that's causing the artifacts you're seeing, but if I figure it out I'll post back.

So it may be, as you suggested initially based on comparison with Blender, that the mesh itself (at least the vertex positions) isn't the culprit. However, it does look to me like the vertex positions aren't welded at the seam and at the poles. (Maybe they are, but I didn't see it in the code.) I'm not seeing any problems because of this, but in principle at least this can lead to 'sparklies' or similar artifacts (which you may already know). In any case, regardless of whether it's an issue, I'd weld the sphere vertices if they're not already.

I don't know why my last post was voted down but I don't appreciate it at all.

As you can see, the UV's are a mess. They actually go outside the  UV limits of 0 to 1 space in several places.

5 hours ago, fleabay said:

The UV's should not go all the way to the edge.

If you want the entire texture on the sphere, yes they should go exactly to the edge.

2 hours ago, Zakwayda said:

I took a look at the project. I think the culprit may be this in your fragment function:

vec2 uvs =  fract(uvcoords).xy * uvtile;

If you remove the fract() call, the artifacts disappear (for me anyway).

This is a DIY way of implementing the "wrap" texture addressing mode (instead of "clamp").

Instead of this shader code, you should just use the wrap mode.

The manual shader method is failing for you because this simple implementation is naive of mip-maps. When you sample from a texture, the derivatives of the UV coordinates are used to select a mip-level. In a correct implementation (which you'll get for free with "wrap" mode), you need to calculate the derivatives before doing the fract operation. If you calculate derivatives afterwards (which is what's happening to you), then the derivatives will be huge along the seam where fract turns 1.01 into 0.01, which leads to a lower mip level being spuriously selected along that seam.

1 hour ago, fleabay said:

As you can see, the UV's are a mess. They actually go outside the  UV limits of 0 to 1 space in several places.

This won't be a problem if you use wrap mode  

One way is to disable bilinear interpolation or use power of 2 texture

2 hours ago, Zakwayda said:

I took a look at the project. I think the culprit may be this in your fragment function:

vec2 uvs =  fract(uvcoords).xy * uvtile;

If you remove the fract() call, the artifacts disappear (for me anyway).

I haven't dug deep enough to tell you exactly why that's causing the artifacts you're seeing, but if I figure it out I'll post back.

So it may be, as you suggested initially based on comparison with Blender, that the mesh itself (at least the vertex positions) isn't the culprit. However, it does look to me like the vertex positions aren't welded at the seam and at the poles. (Maybe they are, but I didn't see it in the code.) I'm not seeing any problems because of this, but in principle at least this can lead to 'sparklies' or similar artifacts (which you may already know). In any case, regardless of whether it's an issue, I'd weld the sphere vertices if they're not already.

Thank you so much! Removing the fract function was exactly the solution! Why was this occurring though? Could it be due to the welding issue, or maybe floating point precision? I'll figure out another way to dynamically tile textures. 

I appreciate all the answers suggested, thanks all. 

Update: 

Hodgeman's answer above explains why this is happening for those of you wondering.

23 minutes ago, Hashbrown said:

Why was this occurring though? Could it be due to the welding issue, or maybe floating point precision? I'll figure out another way to dynamically tile textures.

If you try to put a different texture on that doesn't repeat you will see that your problem still exists with the UV's and most of the solutions here are bandaids for the bigger problem.

ED: It doesn't even have to be a non-repeating texture. Any slightly more complicated texture will give you issues.

17 minutes ago, Hashbrown said:

Could it be due to the welding issue

Welding is something that's done inside your 3d modelling application, but once it's in the 3d engine it's just a list of verts.  All welding does is make verts in the UV space stick together to make it easier to work with.  Once it's rendered everything is disconnected, faces aren't even connected anymore let alone UV stuff.

As for why exactly that's happening, I'm not exactly sure.  All that's doing is making sure the UV coodinates for the fragment are clamped to 0..1.  However, as was pointed out, that's what the texture sampler parameters like clamp and wrap already do, so there's no need for it.

49 minutes ago, gaxio said:

Welding is something that's done inside your 3d modelling application, but once it's in the 3d engine it's just a list of verts.  All welding does is make verts in the UV space stick together to make it easier to work with.  Once it's rendered everything is disconnected, faces aren't even connected anymore let alone UV stuff.

I think the OP is generating the mesh procedurally in code rather than importing it. What I was referring to was vertex positions that should be coincident, but differ due to numerical error. I think there may be some cases of this in the OP's mesh (although it doesn't seem to be causing any artifacts).

Quote

The UV's should not go all the way to the edge.

I didn't down vote, but UV's can go to the edge and further.

Quote

As you can see, the UV's are a mess. They actually go outside the  UV limits of 0 to 1 space in several places.

Again, there is no limit to UV space. It just wraps around unless you request to clamp to edge.